From: Jakub Kicinski <kuba@kernel•org>
To: Stanislav Fomichev <stfomichev@gmail•com>
Cc: sdf@fomichev•me, Kuniyuki Iwashima <kuniyu@amazon•com>,
andrew+netdev@lunn•ch, davem@davemloft•net, edumazet@google•com,
horms@kernel•org, hramamurthy@google•com, jdamato@fastly•com,
netdev@vger•kernel.org, pabeni@redhat•com
Subject: Re: [PATCH net-next v2 6/8] netdev: depend on netdev->lock for xdp features
Date: Fri, 11 Apr 2025 12:19:38 -0700 [thread overview]
Message-ID: <20250411121938.0afae1b3@kernel.org> (raw)
In-Reply-To: <Z_lUZgRc9JYhjnIG@mini-arch>
On Fri, 11 Apr 2025 10:41:58 -0700 Stanislav Fomichev wrote:
> > Ugh, REGISTER is ops locked we'd need conditional locking here.
> >
> > Stanislav, I can make the REGISTERED notifier fully locked, right?
> > I suspect any new object we add that's protected by the instance
> > lock will want to lock the dev.
>
> Are you suggesting to do s/netdev_lock_ops/netdev_lock/ around
> call_netdevice_notifiers in register_netdevice?
Aha
> We can try, the biggest concern, as usual, are the stacking devices
> (with an extra lock), but casually grepping for NETDEV_REGISTER
> doesn't bring up anything suspicious.
>
> But if you're gonna do conditional locking for NETDEV_UNREGISTER, any
> reason not to play it safe and add conditional locking to
> NETDEV_REGISTER in netdev_genl_netdevice_event?
Just trying to think what will lead to fewer problems down the line.
Let's me think it thru. So we have this situation:
- device A - getting registered
- device L - listens / has the notifier
with upper devs our concern is usually that taking the A's lock
around the notifier forces A -> L lock ordering (between A's instance
lock and whatever lock of L, can be either instance or some other).
If A is an arbitrary device then L has to already be ready to handle
its REGISTER callback under A's instance lock, because A may be ops
locked. So as you say for generic bonding/team changing lock type
is a noop.
If A is a specific device that L is looking for - changing the lock type
around REGISTER may impact L. /me goes to look at the code
Ugh there is a bunch of drivers that wait for a specific device to
register and then take a lock. Let me play it safe then...
next prev parent reply other threads:[~2025-04-11 19:19 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-08 19:59 [PATCH net-next v2 0/8] net: depend on instance lock for queue related netlink ops Jakub Kicinski
2025-04-08 19:59 ` [PATCH net-next v2 1/8] net: avoid potential race between netdev_get_by_index_lock() and netns switch Jakub Kicinski
2025-04-08 19:59 ` [PATCH net-next v2 2/8] net: designate XSK pool pointers in queues as "ops protected" Jakub Kicinski
2025-04-08 19:59 ` [PATCH net-next v2 3/8] netdev: add "ops compat locking" helpers Jakub Kicinski
2025-04-08 19:59 ` [PATCH net-next v2 4/8] netdev: don't hold rtnl_lock over nl queue info get when possible Jakub Kicinski
2025-04-08 19:59 ` [PATCH net-next v2 5/8] xdp: double protect netdev->xdp_flags with netdev->lock Jakub Kicinski
2025-04-08 22:15 ` Harshitha Ramamurthy
2025-04-09 18:40 ` Martin KaFai Lau
2025-04-08 19:59 ` [PATCH net-next v2 6/8] netdev: depend on netdev->lock for xdp features Jakub Kicinski
2025-04-10 17:10 ` Kuniyuki Iwashima
2025-04-11 2:10 ` Jakub Kicinski
2025-04-11 2:23 ` Jakub Kicinski
2025-04-11 17:41 ` Stanislav Fomichev
2025-04-11 19:19 ` Jakub Kicinski [this message]
2025-04-11 2:36 ` Kuniyuki Iwashima
2025-04-08 19:59 ` [PATCH net-next v2 7/8] docs: netdev: break down the instance locking info per ops struct Jakub Kicinski
2025-04-09 2:59 ` Joe Damato
2025-04-10 6:01 ` Jacob Keller
2025-04-10 16:08 ` Jakub Kicinski
2025-04-10 22:35 ` Keller, Jacob E
2025-04-10 23:39 ` Jakub Kicinski
2025-04-11 21:26 ` Jacob Keller
2025-04-08 19:59 ` [PATCH net-next v2 8/8] netdev: depend on netdev->lock for qstats in ops locked drivers Jakub Kicinski
2025-04-10 5:23 ` Jacob Keller
2025-04-10 23:46 ` Jakub Kicinski
2025-04-11 21:29 ` Jacob Keller
2025-04-10 0:40 ` [PATCH net-next v2 0/8] net: depend on instance lock for queue related netlink ops patchwork-bot+netdevbpf
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=20250411121938.0afae1b3@kernel.org \
--to=kuba@kernel$(echo .)org \
--cc=andrew+netdev@lunn$(echo .)ch \
--cc=davem@davemloft$(echo .)net \
--cc=edumazet@google$(echo .)com \
--cc=horms@kernel$(echo .)org \
--cc=hramamurthy@google$(echo .)com \
--cc=jdamato@fastly$(echo .)com \
--cc=kuniyu@amazon$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=sdf@fomichev$(echo .)me \
--cc=stfomichev@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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