From: Ido Schimmel <idosch@nvidia.com>
To: David Ahern <dsahern@kernel.org>
Cc: Ao Zhou <n05ec@lzu.edu.cn>,
netdev@vger.kernel.org, "David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Ido Schimmel <idosch@mellanox.com>, Jiri Pirko <jiri@resnulli.us>,
Yifan Wu <yifanwucs@gmail.com>,
Juefei Pu <tomapufckgml@gmail.com>,
Yuan Tan <yuantan098@gmail.com>, Xin Liu <bird@lzu.edu.cn>,
Haoze Xie <royenheart@gmail.com>
Subject: Re: [PATCH net v2 1/1] net: l3mdev: Ignore non-L3 uppers in l3mdev_fib_table_rcu
Date: Tue, 7 Apr 2026 11:02:59 +0300 [thread overview]
Message-ID: <20260407080259.GA760990@shredder> (raw)
In-Reply-To: <b6cc7bc1-f18b-43d2-a21a-c964466fa882@kernel.org>
On Mon, Apr 06, 2026 at 12:14:15PM -0600, David Ahern wrote:
> On 4/6/26 9:48 AM, Ido Schimmel wrote:
> >
> > Don't we have the same problem in l3mdev_l3_rcv() and l3mdev_l3_out()?
> > If so, please check if I missed more places and include them in v3.
> >
> > And I think that the part that I was missing earlier is that we don't
> > have RCU synchronization in the unslaving path, so an RCU reader can
> > either see the original master, NULL or a new master (e.g., bridge
> > instead of the original VRF master).
>
> synchronize_rcu after the unlink (control path) seems like a better,
> more robust option than adding more checks to the datapath.
IMO it would be better to proceed with the original approach and look
into adding RCU synchronization in net-next. The original approach is
more surgical and the pattern of first checking netif_is_l3_master()
already exists in other places.
next prev parent reply other threads:[~2026-04-07 8:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1775062214.git.royenheart@gmail.com>
2026-04-04 11:52 ` [PATCH net 1/1] net: l3mdev: Ignore non-L3 uppers in l3mdev_fib_table_rcu Ao Zhou
2026-04-05 16:22 ` David Ahern
2026-04-06 10:33 ` Ido Schimmel
2026-04-19 3:45 ` Haoze Xie
2026-04-06 13:28 ` [PATCH net v2 " Ao Zhou
2026-04-06 15:48 ` Ido Schimmel
2026-04-06 18:14 ` David Ahern
2026-04-07 8:02 ` Ido Schimmel [this message]
2026-04-19 3:51 ` Haoze Xie
2026-04-19 3:49 ` Haoze Xie
2026-04-19 14:38 ` Haoze Xie
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=20260407080259.GA760990@shredder \
--to=idosch@nvidia.com \
--cc=bird@lzu.edu.cn \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=idosch@mellanox.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=n05ec@lzu.edu.cn \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=royenheart@gmail.com \
--cc=tomapufckgml@gmail.com \
--cc=yifanwucs@gmail.com \
--cc=yuantan098@gmail.com \
/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.