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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).