[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250415001738.91572-1-kuniyu@amazon.com>
Date: Mon, 14 Apr 2025 17:17:10 -0700
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <kuba@...nel.org>
CC: <davem@...emloft.net>, <edumazet@...gle.com>, <horms@...nel.org>,
<kuni1840@...il.com>, <kuniyu@...zon.com>, <netdev@...r.kernel.org>,
<pabeni@...hat.com>
Subject: Re: [PATCH v2 net-next 02/14] net: Add ops_undo_single for module load/unload.
From: Jakub Kicinski <kuba@...nel.org>
Date: Mon, 14 Apr 2025 17:12:05 -0700
> On Mon, 14 Apr 2025 17:01:48 -0700 Jakub Kicinski wrote:
> > On Fri, 11 Apr 2025 13:52:31 -0700 Kuniyuki Iwashima wrote:
> > > + bool hold_rtnl = !!ops->exit_batch_rtnl;
> > > +
> > > + list_add(&ops->list, &ops_list);
> > > + ops_undo_list(&ops_list, NULL, net_exit_list, false, hold_rtnl);
> >
> > Is this the only reason for the hold_rtnl argument to ops_undo_list() ?
> > We walk the ops once for pre-exit, before calling rtnl batch.
> > As we walk them we can |= their exit_batch_rtnl pointers, so
> > ops_undo_list() can figure out whether its worth taking rtnl all by itself ?
nexthop is the only built-in user of ->exit_rtnl(), so hold_rtnl
will be always true for setup/cleanup_net().
>
> Either way -- this would fit quite nicely as its own patch so please
> follow up if you agree. I'll apply the series as is.
But I like that way so will post a follow up in case we can get
rid of ->exit_rtnl() from nexthop in the future.
Thanks!
Powered by blists - more mailing lists