[PATCH] 9p/xen: Use flexible array for data rings

[PATCH] 9p/xen: Use flexible array for data rings

[Rosen Penev]

Store the fixed set of Xen 9p data rings in the frontend private
allocation instead of allocating a separate rings array.

This keeps the data ring storage tied to the frontend lifetime and
simplifies the allocation and cleanup paths.

Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 net/9p/trans_xen.c | 68 ++++++++++++++++++++--------------------------
 1 file changed, 30 insertions(+), 38 deletions(-)

diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index f9fb2db7a066..5a110d71d18c 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -55,7 +55,7 @@ struct xen_9pfs_front_priv {
 	char *tag;
 	struct p9_client *client;
 
-	struct xen_9pfs_dataring *rings;
+	struct xen_9pfs_dataring rings[];
 };
 
 static LIST_HEAD(xen_9pfs_devs);
@@ -277,41 +277,38 @@ static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv)
 {
 	int i, j;
 
-	if (priv->rings) {
-		for (i = 0; i < XEN_9PFS_NUM_RINGS; i++) {
-			struct xen_9pfs_dataring *ring = &priv->rings[i];
+	for (i = 0; i < XEN_9PFS_NUM_RINGS; i++) {
+		struct xen_9pfs_dataring *ring = &priv->rings[i];
 
-			cancel_work_sync(&ring->work);
+		cancel_work_sync(&ring->work);
 
-			if (!ring->intf)
-				break;
-			if (ring->irq >= 0) {
-				unbind_from_irqhandler(ring->irq, ring);
-				ring->irq = -1;
-			}
-			if (ring->data.in) {
-				for (j = 0; j < (1 << ring->intf->ring_order);
-				     j++) {
-					grant_ref_t ref;
-
-					ref = ring->intf->ref[j];
-					gnttab_end_foreign_access(ref, NULL);
-					ring->intf->ref[j] = INVALID_GRANT_REF;
-				}
-				free_pages_exact(ring->data.in,
-						 1UL << (ring->intf->ring_order +
-							 XEN_PAGE_SHIFT));
-				ring->data.in = NULL;
-				ring->data.out = NULL;
-			}
-			if (ring->ref != INVALID_GRANT_REF) {
-				gnttab_end_foreign_access(ring->ref, NULL);
-				ring->ref = INVALID_GRANT_REF;
+		if (!ring->intf)
+			break;
+		if (ring->irq >= 0) {
+			unbind_from_irqhandler(ring->irq, ring);
+			ring->irq = -1;
+		}
+		if (ring->data.in) {
+			for (j = 0; j < (1 << ring->intf->ring_order);
+			     j++) {
+				grant_ref_t ref;
+
+				ref = ring->intf->ref[j];
+				gnttab_end_foreign_access(ref, NULL);
+				ring->intf->ref[j] = INVALID_GRANT_REF;
 			}
-			free_page((unsigned long)ring->intf);
-			ring->intf = NULL;
+			free_pages_exact(ring->data.in,
+					 1UL << (ring->intf->ring_order +
+						 XEN_PAGE_SHIFT));
+			ring->data.in = NULL;
+			ring->data.out = NULL;
 		}
-		kfree(priv->rings);
+		if (ring->ref != INVALID_GRANT_REF) {
+			gnttab_end_foreign_access(ring->ref, NULL);
+			ring->ref = INVALID_GRANT_REF;
+		}
+		free_page((unsigned long)ring->intf);
+		ring->intf = NULL;
 	}
 	kfree(priv->tag);
 	kfree(priv);
@@ -446,15 +443,10 @@ static int xen_9pfs_front_init(struct xenbus_device *dev)
 	if (p9_xen_trans.maxsize > XEN_FLEX_RING_SIZE(max_ring_order))
 		p9_xen_trans.maxsize = XEN_FLEX_RING_SIZE(max_ring_order) / 2;
 
-	priv = kzalloc_obj(*priv);
+	priv = kzalloc_flex(*priv, rings, XEN_9PFS_NUM_RINGS);
 	if (!priv)
 		return -ENOMEM;
 	priv->dev = dev;
-	priv->rings = kzalloc_objs(*priv->rings, XEN_9PFS_NUM_RINGS);
-	if (!priv->rings) {
-		kfree(priv);
-		return -ENOMEM;
-	}
 
 	for (i = 0; i < XEN_9PFS_NUM_RINGS; i++) {
 		priv->rings[i].priv = priv;
-- 
2.54.0

Re: [PATCH] 9p/xen: Use flexible array for data rings

[Jürgen Groß]

[-- Attachment #1.1.1: Type: text/plain, Size: 1002 bytes --]

On 19.05.26 03:57, Rosen Penev wrote:
> Store the fixed set of Xen 9p data rings in the frontend private
> allocation instead of allocating a separate rings array.
> 
> This keeps the data ring storage tied to the frontend lifetime and
> simplifies the allocation and cleanup paths.
> 
> Assisted-by: Codex:GPT-5.5
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
>   net/9p/trans_xen.c | 68 ++++++++++++++++++++--------------------------
>   1 file changed, 30 insertions(+), 38 deletions(-)
> 
> diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> index f9fb2db7a066..5a110d71d18c 100644
> --- a/net/9p/trans_xen.c
> +++ b/net/9p/trans_xen.c
> @@ -55,7 +55,7 @@ struct xen_9pfs_front_priv {
>   	char *tag;
>   	struct p9_client *client;
>   
> -	struct xen_9pfs_dataring *rings;
> +	struct xen_9pfs_dataring rings[];

Any reason not to use rings[XEN_9PFS_NUM_RINGS] instead of a flex array?

The number of rings is a compile time constant, after all!


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH] 9p/xen: Use flexible array for data rings

[Rosen Penev]

On Tue, May 26, 2026 at 10:39 PM Jürgen Groß <jgross@suse.com> wrote:
>
> On 19.05.26 03:57, Rosen Penev wrote:
> > Store the fixed set of Xen 9p data rings in the frontend private
> > allocation instead of allocating a separate rings array.
> >
> > This keeps the data ring storage tied to the frontend lifetime and
> > simplifies the allocation and cleanup paths.
> >
> > Assisted-by: Codex:GPT-5.5
> > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > ---
> >   net/9p/trans_xen.c | 68 ++++++++++++++++++++--------------------------
> >   1 file changed, 30 insertions(+), 38 deletions(-)
> >
> > diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> > index f9fb2db7a066..5a110d71d18c 100644
> > --- a/net/9p/trans_xen.c
> > +++ b/net/9p/trans_xen.c
> > @@ -55,7 +55,7 @@ struct xen_9pfs_front_priv {
> >       char *tag;
> >       struct p9_client *client;
> >
> > -     struct xen_9pfs_dataring *rings;
> > +     struct xen_9pfs_dataring rings[];
>
> Any reason not to use rings[XEN_9PFS_NUM_RINGS] instead of a flex array?
>
> The number of rings is a compile time constant, after all!
flexibility really. I don't know if this will ever change.
>
>
> Juergen

Re: [PATCH] 9p/xen: Use flexible array for data rings

[Jürgen Groß]

[-- Attachment #1.1.1: Type: text/plain, Size: 1312 bytes --]

On 27.05.26 08:38, Rosen Penev wrote:
> On Tue, May 26, 2026 at 10:39 PM Jürgen Groß <jgross@suse.com> wrote:
>>
>> On 19.05.26 03:57, Rosen Penev wrote:
>>> Store the fixed set of Xen 9p data rings in the frontend private
>>> allocation instead of allocating a separate rings array.
>>>
>>> This keeps the data ring storage tied to the frontend lifetime and
>>> simplifies the allocation and cleanup paths.
>>>
>>> Assisted-by: Codex:GPT-5.5
>>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
>>> ---
>>>    net/9p/trans_xen.c | 68 ++++++++++++++++++++--------------------------
>>>    1 file changed, 30 insertions(+), 38 deletions(-)
>>>
>>> diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
>>> index f9fb2db7a066..5a110d71d18c 100644
>>> --- a/net/9p/trans_xen.c
>>> +++ b/net/9p/trans_xen.c
>>> @@ -55,7 +55,7 @@ struct xen_9pfs_front_priv {
>>>        char *tag;
>>>        struct p9_client *client;
>>>
>>> -     struct xen_9pfs_dataring *rings;
>>> +     struct xen_9pfs_dataring rings[];
>>
>> Any reason not to use rings[XEN_9PFS_NUM_RINGS] instead of a flex array?
>>
>> The number of rings is a compile time constant, after all!
> flexibility really. I don't know if this will ever change.

If it ever changes we can still switch to a flex array.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]