From: Simon Horman <horms@kernel.org>
To: Shradha Gupta <shradhagupta@linux.microsoft.com>
Cc: linux-hardening@vger.kernel.org, netdev@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rdma@vger.kernel.org,
Colin Ian King <colin.i.king@gmail.com>,
Ahmed Zaki <ahmed.zaki@intel.com>,
Pavan Chebbi <pavan.chebbi@broadcom.com>,
Souradeep Chakrabarti <schakrabarti@linux.microsoft.com>,
Konstantin Taranov <kotaranov@microsoft.com>,
Kees Cook <keescook@chromium.org>,
Paolo Abeni <pabeni@redhat.com>, Jakub Kicinski <kuba@kernel.org>,
Eric Dumazet <edumazet@google.com>,
"David S. Miller" <davem@davemloft.net>,
Dexuan Cui <decui@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
Haiyang Zhang <haiyangz@microsoft.com>,
"K. Y. Srinivasan" <kys@microsoft.com>,
Leon Romanovsky <leon@kernel.org>, Jason Gunthorpe <jgg@ziepe.ca>,
Long Li <longli@microsoft.com>,
Shradha Gupta <shradhagupta@microsoft.com>
Subject: Re: [PATCH net-next v3] net: mana: Allow variable size indirection table
Date: Thu, 6 Jun 2024 17:33:34 +0100 [thread overview]
Message-ID: <20240606163334.GO791188@kernel.org> (raw)
In-Reply-To: <20240605083906.GA15889@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
On Wed, Jun 05, 2024 at 01:39:06AM -0700, Shradha Gupta wrote:
> On Tue, Jun 04, 2024 at 10:33:49AM +0100, Simon Horman wrote:
> > On Fri, May 31, 2024 at 08:37:41AM -0700, Shradha Gupta wrote:
> > > Allow variable size indirection table allocation in MANA instead
> > > of using a constant value MANA_INDIRECT_TABLE_SIZE.
> > > The size is now derived from the MANA_QUERY_VPORT_CONFIG and the
> > > indirection table is allocated dynamically.
> > >
> > > Signed-off-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
> > > Reviewed-by: Dexuan Cui <decui@microsoft.com>
> > > Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
> >
> > ...
> >
> > > diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
> >
> > ...
> >
> > > @@ -2344,11 +2352,33 @@ static int mana_create_vport(struct mana_port_context *apc,
> > > return mana_create_txq(apc, net);
> > > }
> > >
> > > +static int mana_rss_table_alloc(struct mana_port_context *apc)
> > > +{
> > > + if (!apc->indir_table_sz) {
> > > + netdev_err(apc->ndev,
> > > + "Indirection table size not set for vPort %d\n",
> > > + apc->port_idx);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + apc->indir_table = kcalloc(apc->indir_table_sz, sizeof(u32), GFP_KERNEL);
> > > + if (!apc->indir_table)
> > > + return -ENOMEM;
> > > +
> > > + apc->rxobj_table = kcalloc(apc->indir_table_sz, sizeof(mana_handle_t), GFP_KERNEL);
> > > + if (!apc->rxobj_table) {
> > > + kfree(apc->indir_table);
> >
> > Hi, Shradha
> >
> > Perhaps I am on the wrong track here, but I have some concerns
> > about clean-up paths.
> >
> > Firstly. I think that apc->indir_table should be to NULL here for
> > consistency with other clean-up paths. Or alternatively, fields of apc
> > should not set to NULL elsewhere after being freed.
>
> Hi Simon,
>
> Thanks for the comments. This makes sense, I am planning of consistently
> removing the NULLify from other places too as per Leon's comments.
Great!
> > In looking into this I noticed that mana_probe() does not call
> > mana_remove() or return an error in the cases where mana_probe_port()
> > or mana_attach() fail unless add_adev also fails. If so, is that
> > intentional?
>
> Right, so most calls like mana_probe_port(), mana_attach() cleanup after
> themselves in the code if there is any error. So, not having to call
> mana_remove() in these cases in mana_probe() is intentional. But I do
> agree that an error is returned in mana_probe() only if add_adev also
> fails. I'll fix that too in the next version
I'm not entirely sure, but perhaps that is a candidate for a separate patch.
> >
> > In any case, I would suggest as a follow-up, arranging things so that
> > when an error occurs in a function, anything that was allocated is
> > unwound before returning an error.
> >
> > I think this would make allocation/deallocation easier to reason with.
> > And I suspect it would avoid both the need for fields of structures to
> > be zeroed after being freed, and the need to call mana_remove() from
> > mana_probe().
>
> Agreed
> >
> > > + return -ENOMEM;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > static void mana_rss_table_init(struct mana_port_context *apc)
> > > {
> > > int i;
> > >
> > > - for (i = 0; i < MANA_INDIRECT_TABLE_SIZE; i++)
> > > + for (i = 0; i < apc->indir_table_sz; i++)
> > > apc->indir_table[i] =
> > > ethtool_rxfh_indir_default(i, apc->num_queues);
> > > }
> >
> > ...
> >
> > > @@ -2739,11 +2772,17 @@ static int mana_probe_port(struct mana_context *ac, int port_idx,
> > > err = register_netdev(ndev);
> > > if (err) {
> > > netdev_err(ndev, "Unable to register netdev.\n");
> > > - goto reset_apc;
> > > + goto free_indir;
> > > }
> > >
> > > return 0;
> > >
> > > +free_indir:
> > > + apc->indir_table_sz = 0;
> > > + kfree(apc->indir_table);
> > > + apc->indir_table = NULL;
> > > + kfree(apc->rxobj_table);
> > > + apc->rxobj_table = NULL;
> > > reset_apc:
> > > kfree(apc->rxqs);
> > > apc->rxqs = NULL;
> >
> > nit: Not strictly related to this patch, but the reset_apc code should
> > probably be a call to mana_cleanup_port_context() as it is the dual of
> > mana_init_port_context() which is called earlier in mana_probe_port()
>
> Sure, let me do that too.
FWIIW, I think it would be appropriate to put that change in a separate patch.
> >
> > ...
> >
> > > @@ -2931,6 +2972,11 @@ void mana_remove(struct gdma_dev *gd, bool suspending)
> > > }
> > >
> > > unregister_netdevice(ndev);
> > > + apc->indir_table_sz = 0;
> > > + kfree(apc->indir_table);
> > > + apc->indir_table = NULL;
> > > + kfree(apc->rxobj_table);
> > > + apc->rxobj_table = NULL;
> >
> > The code to free and zero indir_table_sz and indir_table appears twice
> > in this patch. Perhaps a helper to do this, which would be the dual
> > of mana_rss_table_alloc is in order.
> Makes sense, will change this too.
Thanks.
next prev parent reply other threads:[~2024-06-06 16:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-31 15:37 [PATCH net-next v3] net: mana: Allow variable size indirection table Shradha Gupta
2024-06-03 8:41 ` Leon Romanovsky
2024-06-04 5:36 ` Shradha Gupta
2024-06-04 8:32 ` Leon Romanovsky
2024-06-04 9:01 ` Shradha Gupta
2024-06-04 9:33 ` Simon Horman
2024-06-05 8:39 ` Shradha Gupta
2024-06-06 16:33 ` Simon Horman [this message]
2024-06-11 5:31 ` Shradha Gupta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240606163334.GO791188@kernel.org \
--to=horms@kernel.org \
--cc=ahmed.zaki@intel.com \
--cc=colin.i.king@gmail.com \
--cc=davem@davemloft.net \
--cc=decui@microsoft.com \
--cc=edumazet@google.com \
--cc=haiyangz@microsoft.com \
--cc=jgg@ziepe.ca \
--cc=keescook@chromium.org \
--cc=kotaranov@microsoft.com \
--cc=kuba@kernel.org \
--cc=kys@microsoft.com \
--cc=leon@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.com \
--cc=schakrabarti@linux.microsoft.com \
--cc=shradhagupta@linux.microsoft.com \
--cc=shradhagupta@microsoft.com \
--cc=wei.liu@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.