From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 77E9038E10F for ; Wed, 22 Apr 2026 16:20:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776874847; cv=none; b=RSLDrPB/lsk7QI9CZpTTsjHRtoD6OYKrs8Ses/dwTJLancG3R+a+em9t+M7mTRyb7miLY1MnCkJHTIJRSWMzV+IY+NIdSKhd1cFPPfW1gVIZE0hxPfQrUuUA/MK40kX8VyFLi+4cATkdYMfuqdCbfooPWVT5r939xlrtdzPEF4Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776874847; c=relaxed/simple; bh=552f9hdt0Q9xyd/Cb6oPTHWO+NEzOX+2d/uM6MbS2OI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mWsXeGPBmLaoDrZQHwG/8C34DQR5IC3/F2uIqywgD/rCamdYdZnvzJ7auFYio3OgHi9JiPGiHGZMj/kwmG4tq0o+0J/C7CiNRkp9RbxKDDTYqXPHYuyRzNK8RRYSgXe5Fig5FrasJwkRL77GX3wBQhGSFt9LQFaO6YGp9qQAha8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BgjTxvBi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BgjTxvBi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2FBBBC19425; Wed, 22 Apr 2026 16:20:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776874847; bh=552f9hdt0Q9xyd/Cb6oPTHWO+NEzOX+2d/uM6MbS2OI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BgjTxvBi83hfTofpSFlo88+EJuEGRVFDeCZ/l18hrUWBXQzTJx1U4781OKv4OGGDC pwV6W9Z3sMF93ezLbQFQ9/9pRGe3DefnQLvASUtPOZ/5qYczxj4gkif4DzEzKlB7w0 fHCQuGl+2kcwbax+S7ICOP7xmo6q7P4zxL9g3d9e4t9qvE3nIEs6bmz/U7qfYbOGfA im/HSL0eFRevOvaVgE12KPYM8SC+wuP6B/Myn5MvMl1tAYxpygLDyIABNFKyoTPdsg OMPO2BcInv8IIxBX1qbTguitq2wTEX86fZAksrLVPgkSDpt98V31n5xeTdOXxrjc5P WTZCzF/rpZ1yw== Date: Wed, 22 Apr 2026 17:20:41 +0100 From: Simon Horman To: Ren Wei Cc: netdev@vger.kernel.org, edumazet@google.com, andrew+netdev@lunn.ch, davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, kees@kernel.org, yuantan098@gmail.com, ylong030@ucr.edu, yifanwucs@gmail.com, tomapufckgml@gmail.com, bird@lzu.edu.cn Subject: Re: [PATCH net v2 2/2] 8021q: delete cleared egress QoS mappings Message-ID: <20260422162041.GO651125@horms.kernel.org> References: <9136768189f8c6d3f824f476c62d2fa1111688e8.1776647968.git.yuantan098@gmail.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Apr 20, 2026 at 11:18:46AM +0800, Ren Wei wrote: > From: Longxuan Yu > > vlan_dev_set_egress_priority() currently keeps cleared egress > priority mappings in the hash as tombstones. Repeated set/clear cycles > with distinct skb priorities therefore accumulate mapping nodes until > device teardown and leak memory. > > Delete mappings when vlan_prio is cleared instead of keeping tombstones. > Now that the egress mapping lists are RCU protected, the node can be > unlinked safely and freed after a grace period. > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Cc: stable@kernel.org > Reported-by: Yifan Wu > Reported-by: Juefei Pu > Reported-by: Xin Liu > Co-developed-by: Yuan Tan > Signed-off-by: Yuan Tan > Signed-off-by: Longxuan Yu > Signed-off-by: Ren Wei > --- > net/8021q/vlan_dev.c | 20 ++++++++++++++------ > net/8021q/vlan_netlink.c | 4 ---- > 2 files changed, 14 insertions(+), 10 deletions(-) > > diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c > index a5340932b657..7aa3af8b10ea 100644 > --- a/net/8021q/vlan_dev.c > +++ b/net/8021q/vlan_dev.c > @@ -172,26 +172,34 @@ int vlan_dev_set_egress_priority(const struct net_device *dev, > u32 skb_prio, u16 vlan_prio) > { > struct vlan_dev_priv *vlan = vlan_dev_priv(dev); > + struct vlan_priority_tci_mapping __rcu **mpp; > struct vlan_priority_tci_mapping *mp; > struct vlan_priority_tci_mapping *np; > u32 bucket = skb_prio & 0xF; > u32 vlan_qos = (vlan_prio << VLAN_PRIO_SHIFT) & VLAN_PRIO_MASK; > > /* See if a priority mapping exists.. */ > - mp = rtnl_dereference(vlan->egress_priority_map[bucket]); > + mpp = &vlan->egress_priority_map[bucket]; > + mp = rtnl_dereference(*mpp); > while (mp) { > if (mp->priority == skb_prio) { > - if (mp->vlan_qos && !vlan_qos) > + if (!vlan_qos) { > + rcu_assign_pointer(*mpp, rtnl_dereference(mp->next)); > vlan->nr_egress_mappings--; > - else if (!mp->vlan_qos && vlan_qos) > - vlan->nr_egress_mappings++; > - WRITE_ONCE(mp->vlan_qos, vlan_qos); > + kfree_rcu(mp, rcu); > + } else { > + WRITE_ONCE(mp->vlan_qos, vlan_qos); > + } > return 0; > } > - mp = rtnl_dereference(mp->next); > + mpp = &mp->next; > + mp = rtnl_dereference(*mpp); > } Hi Ren, Thanks for splitting up the patchset, it is very helpful to me. It seems to me that the mpp/mp construct used is a bit complex and stems from the use of a hand-rolled list centred the next field of struct vlan_priority_tci_mapping. I wonder if things can be simplified by moving to use a standardised list construct, such as an hlist. And the helpers available for using it. > > /* Create a new mapping then. */ > + if (!vlan_qos) > + return 0; > + > np = kmalloc_obj(struct vlan_priority_tci_mapping); > if (!np) > return -ENOBUFS; ...