From: Simon Horman <horms@kernel.org>
To: n05ec@lzu.edu.cn
Cc: 'Simon Horman' <horms@kernel.org>,
netdev@vger.kernel.org, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, kees@kernel.org, yifanwucs@gmail.com,
tomapufckgml@gmail.com, yuantan098@gmail.com, bird@lzu.edu.cn,
ylong030@ucr.edu
Subject: Re: [PATCH net 1/1] 8021q: free cleared egress QoS mappings safely
Date: Wed, 15 Apr 2026 15:47:28 +0100 [thread overview]
Message-ID: <20260415144727.810720-2-horms@kernel.org> (raw)
In-Reply-To: <b877895cd02d35254b5c05d3c40abbf130cd87eb.1776039122.git.ylong030@ucr.edu>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
8021q: free cleared egress QoS mappings safely
This commit converts the 802.1Q egress priority mapping lists to use
RCU-protected pointers instead of keeping tombstones. It deletes mappings
when vlan_prio is cleared, deferring the freeing of removed nodes until
after an RCU grace period.
> diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c
> index a000b1ef05206..bbe7cbd97939d 100644
> --- a/net/8021q/vlan_netlink.c
> +++ b/net/8021q/vlan_netlink.c
> @@ -260,13 +260,10 @@ static int vlan_fill_info(struct sk_buff *skb, const struct net_device *dev)
> goto nla_put_failure;
>
> for (i = 0; i < ARRAY_SIZE(vlan->egress_priority_map); i++) {
> - for (pm = vlan->egress_priority_map[i]; pm;
> - pm = pm->next) {
> - if (!pm->vlan_qos)
> - continue;
> -
> + for (pm = rtnl_dereference(vlan->egress_priority_map[i]); pm;
> + pm = rtnl_dereference(pm->next)) {
Is it safe to use rtnl_dereference() for this traversal?
The vlan_fill_info() function implements the rtnl_link_ops->fill_info
callback, which is invoked by rtnl_dump_ifinfo() to service interface
netlink dumps. Modern netlink dumps can operate locklessly under
rcu_read_lock() without acquiring the RTNL lock.
Using rtnl_dereference() expands to rcu_dereference_protected(), which
might trigger a lockdep warning when the RTNL lock is not held.
Additionally, it omits the memory barriers needed for safe RCU reader
traversal. Without these barriers, concurrent updates from
vlan_dev_set_egress_priority() could cause the lockless reader to observe
stale or uninitialized list nodes.
Would using rcu_dereference_rtnl() or rcu_dereference() here be more
appropriate to ensure safe lockless traversal during netlink dumps?
> m.from = pm->priority;
> - m.to = (pm->vlan_qos >> 13) & 0x7;
> + m.to = (READ_ONCE(pm->vlan_qos) >> 13) & 0x7;
> if (nla_put(skb, IFLA_VLAN_QOS_MAPPING,
> sizeof(m), &m))
> goto nla_put_failure;
next prev parent reply other threads:[~2026-04-15 14:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1776039122.git.ylong030@ucr.edu>
2026-04-13 9:07 ` [PATCH net 1/1] 8021q: free cleared egress QoS mappings safely Ren Wei
2026-04-15 14:47 ` Simon Horman [this message]
2026-04-15 15:15 ` Simon Horman
2026-04-16 5:35 ` Yuan Tan
2026-04-16 13:34 ` Simon Horman
2026-04-15 16:25 ` Eric Dumazet
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=20260415144727.810720-2-horms@kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=bird@lzu.edu.cn \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kees@kernel.org \
--cc=kuba@kernel.org \
--cc=n05ec@lzu.edu.cn \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=tomapufckgml@gmail.com \
--cc=yifanwucs@gmail.com \
--cc=ylong030@ucr.edu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox