From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B61E842BE8D for ; Fri, 24 Jul 2026 12:41:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784896897; cv=none; b=M8yBTOWsRx2Zd/VJfByzS+0nePpv8au/0t40rEzOhVeXKiWmjkf0vIstah5d92ED1vHe71t+AKCoxsEK1KkVFSADaBcoi0OM83pSnkqCAcs0WeHTZD56OjlWkFH99/PsP8+9LdjM8lXWRDgXATAA1jx1vBTSMtRNxYI8uNPonL8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784896897; c=relaxed/simple; bh=qGvZtVLF1PNj59LPI2pzdZUORCzbf/cryffMvuk7n5w=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FtD6xz22pDb/tj49H3O4IG0mLLipHCSqW9G857csedmn7WJTnHNVPdbKMeXdYsteOQ/ca7TQnGiErvPlL+I2aHrtG8qAhJINDF+UT6SEUY9A1XB5MsyEnxQ/J2gLViDuAoAqXgQbYN9PhZ3GgpjsFVKD29UUbo6941pz/dLWwU4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Bd6Ko7G5; arc=none smtp.client-ip=209.85.221.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Bd6Ko7G5" Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-47df6a5655aso42135f8f.1 for ; Fri, 24 Jul 2026 05:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784896893; x=1785501693; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=dVob7c+v3aI7MKDefWCNuMOS0UxDiJWUoQOuHz5yVOQ=; b=Bd6Ko7G5diOFyHz/Y57ycPG3NYp/x4+kky97fLaL6FAIBSELAH9SEz3PFx8F12tEHh e5kBBS5xijsyY11w9BI5XuEEt7fPeKZaISHj3bNhxakfFKjIn8nrsvvFKyQydjPHYtKU N1BOuEmX2Z/P7W/+DsHV/QaOZSkhD12QKk2jOD7ccbdlTpSVmwRSSzdIdgxgFP47qDsc Mn6YWqeBMVpMqdYqh1sc5zHSzA4drXVFw8bNNEKiDLa8uyHDbKb8VOE6x7ML8ePw/FhC NGRRlO+f1g/Mc78w80MP64EwFbMWdolbm6JNamHikv9StTmx0WEHO91eS9h0l8z7lOQR ehoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784896893; x=1785501693; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=dVob7c+v3aI7MKDefWCNuMOS0UxDiJWUoQOuHz5yVOQ=; b=HRMNsL9PNomm2smCkyGXK+AuH08hS7ZymIWHToICeAwubg/zBbbWwPer2p3okhtsXU ro0a2klgx+Xfp+oJNUKird8DnjedHAnKWJcL0ilAwFO+yJPq6My2RVUAlleV2hJQ+Oxj fBkyiB72st6IbhAM/0135T3BwtTGEHqhVx2j9oRt/RqAHYnWFlv2tq4FuY9Q5QbY8Tyd euPr6MNEMfTzR8MsjgQ6WkXpivee5WIlrUXj5loCblvGbgzXfnnTo6FFc/z43IM2zKpb yDc6qDxq/t7J03jPvFZOcYXJ2T13IZEzAhYLk+Sy73hQjg/FXyLNNIGbNuEOLtoMLq4u TAWA== X-Forwarded-Encrypted: i=1; AHgh+RpkvaDhunwdNtk3Fu6ZVvZ+Xw31rTYZSo73JC/gSE6ussLP7ivct0bl3Y6p0p7JXY0938m372lAu3nMqJY=@vger.kernel.org X-Gm-Message-State: AOJu0YwLmdBaWQeR6qBdoB7PEXUyxTNcWUgsabcRy49UNhjK66alHbsA Y0hz3UwwVpZ3Uls2U2qg3dHso+tWNfSc5nNE711aRAICawS4XnF94ns6 X-Gm-Gg: AR+sD12C7141FEaWpfN/ZvAovzYgVSPTguRTqQGp0dHzqsPqM4BqxINC4PiZ57wPbKs JF/09xQPm2mrwX8UkjpRQnZmvJ7P4lFMJYvS8eBy59bmT7X5WxhN9QsTE0YnGKqcMZRYm4KzuDR piar5xB3pOa//HyRef1C4n/ULY9Rksjs1qRMscTbbJmmtpKoh8E+hMpiCZxeFrK8rMcGV/ej+QW 50ZlxmE2QV3exzxudx7h3gXvGzgDglsyYKEQT0fDCTaEsROC2x4wRM2K2qbq+vfVfFMJn2F5I0n lbuJ8EmaatU7wVGZQjTJ7I4qj4o+mFLp4GW0v47yFkRZomUbXfizyKyGdbmAfopORIul0kj66+y tg7U8neH/DQGm8m23K4S2epCTlymQOH6Hv50enTiovdFTtkBis8siQ6DfdQCD8xbDJ1El X-Received: by 2002:a05:600c:4f82:b0:495:64c5:c6dc with SMTP id 5b1f17b1804b1-49573cfaa4emr46736005e9.5.1784896892670; Fri, 24 Jul 2026 05:41:32 -0700 (PDT) Received: from skbuf ([2a02:2f04:d801:b100:414a:1dac:6b40:cc91]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4957bfb20ddsm42855935e9.3.2026.07.24.05.41.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jul 2026 05:41:31 -0700 (PDT) Date: Fri, 24 Jul 2026 15:41:28 +0300 From: Vladimir Oltean To: Daniel Golle Cc: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Russell King , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next] net: dsa: unsync host addresses when destroying user port Message-ID: <20260724124128.f4327icrjw4jmkrl@skbuf> References: <34a027de7d860796d37de2f2108337eb82110144.1784679091.git.daniel@makrotopia.org> <20260723225735.b7muegd4dlc6wsxz@skbuf> Precedence: bulk X-Mailing-List: linux-kernel@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: <20260723225735.b7muegd4dlc6wsxz@skbuf> On Fri, Jul 24, 2026 at 01:57:35AM +0300, Vladimir Oltean wrote: > On Wed, Jul 22, 2026 at 01:12:47AM +0100, Daniel Golle wrote: > > When a user port is destroyed while addresses are still synced to it, > > e.g. multicast addresses synced by a bridge the port is a member of, > > the host FDB/MDB entries these addresses installed on the CPU port are > > never removed: the only removal path is dsa_user_unsync_uc()/_mc() via > > ndo_set_rx_mode, and __dev_set_rx_mode() does not call the ndo on a > > device which is down. By the time the bridge unsyncs its addresses in > > del_nbp() during unregistration, the netdev has already been closed, > > so the unsync never reaches DSA and the entries linger until > > dsa_switch_release_ports() reports them: > > > > Cleaning up multicast address 33:33:00:00:00:01 vid 0 from port 9 > > > > This happens on every unbind of a DSA driver supporting host address > > filtering while its ports are up. > > > > Unsync the host addresses in dsa_user_destroy() before unregistering > > the netdev, at a point where the driver can still process the > > deletion, just like dsa_user_change_conduit() already does when > > migrating host addresses to a new conduit. > > > > Signed-off-by: Daniel Golle > > --- > > net/dsa/user.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/net/dsa/user.c b/net/dsa/user.c > > index 03c7af6abe18..a7dabb645036 100644 > > --- a/net/dsa/user.c > > +++ b/net/dsa/user.c > > @@ -2885,6 +2885,7 @@ void dsa_user_destroy(struct net_device *user_dev) > > > > netif_carrier_off(user_dev); > > rtnl_lock(); > > + dsa_user_unsync_ha(user_dev); > > netdev_upper_dev_unlink(conduit, user_dev); > > unregister_netdevice(user_dev); > > phylink_disconnect_phy(dp->pl); > > -- > > 2.55.0 > > Sorry, I noticed this patch late. Something doesn't add up - I don't > understand what makes the unregistration path unique, since according to > all you've said, it should be enough to remove the user port from the > bridge while administratively down, and it should lead to the same > effect (no unsync event triggered). In that case, maybe the > dsa_user_unsync_ha() belongs somewhere in dsa_user_close(), near > dsa_user_host_uc_uninstall(). > > I will return tomorrow with more comments after I do some testing. Back with some more comments. Your statement "multicast addresses synced by a bridge the port is a member of" is not correct. The bridge does not call dev_mc_add(). The multicast addresses come from a different place - likely from net/ipv6/mcast.c instead. Therefore, the part of the explanation that ties del_nbp() to the chain of events truly has no relationship and should be dropped. The host-joined multicast groups for the bridge are all synced to hardware through the SWITCHDEV_OBJ_ID_HOST_MDB mechanism. The minimal reproducer for the problem you observed should be: $ ip link set swp0 up $ ip link set swp0 down $ echo > /path/to/driver/unbind and the correct fix is to put the dsa_user_unsync_ha() call where I suggested earlier - in dsa_user_close(). pw-bot: cr