From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 4B6703E4C84 for ; Thu, 23 Jul 2026 22:57:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784847463; cv=none; b=lu39Ref5JKAEJJr5TlEIQ5VulciFZdnwAYfepE5a+w8mMW7dw8mXMh4SuSQhrE3N9ALOYo30V203Zu2TCfep+jqhG0l6VJC5QvOzZQ8DaLOH1SyU4c+kmmTAfUwLcNmu1euO274bjbVsm7C+MEzcJN18oRnZl+Mthcp13qoKeLI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784847463; c=relaxed/simple; bh=9ygC3ApjsClHN3F8iOri1ieGPbycbgI4m3RKD2BIDB4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=s11roCDoUtCxZpoFVgQOEu73hisvgYCcZuf7Vrwwp+2hZkxrdg9pzGiv6gf5nI2JBNZ1eERi4opwSDcApju20w3Y9ixZ89VuVS5GTG9AH/b3qjxSi7Oo1WgGR1ySuIGi0iOaaowI3q6F+Vs0IA5LOGoq1GlrYDBFt8p7NszPeuQ= 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=LRqD4EXZ; arc=none smtp.client-ip=209.85.128.54 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="LRqD4EXZ" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-49544f26c43so1256655e9.0 for ; Thu, 23 Jul 2026 15:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784847460; x=1785452260; 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=Ga5q/gDe3noE1zvv1qzIbxX9qih9+DEY4gSM50nlE0I=; b=LRqD4EXZ1QcuOUZk+DVqtE+Ptk22/PL/TJBEHlN5JRpTNyJ8AFqVAwx3wxDcRmkd7F td5nJ9cRqiZaRpiLKsVjzMddIDFCMSM9gCUm9FuLq1Xt5hlVWBoWYa8sP/5DH0oxP0Lv d7+7g5BALn3ROyMQbWEdFfnCu17qX6RIlZs5wk/aB7xBWbFtgXwMiZD3BrprQ+qF6Mkp FW3VXCaRznao1qQGjbuvZKp1x/xRqHFYyCXK0zELJFSRbtvt7m3hqCoh3VTDRm8Mx0EN pHa2bObzxjIZuRVJzDyC/2V4c7oF7kg32jdsaGsgu+zvs0VMwltEcU1+Jyw3Ma5XJiWG igSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784847460; x=1785452260; 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=Ga5q/gDe3noE1zvv1qzIbxX9qih9+DEY4gSM50nlE0I=; b=R/jylAA+LfuhRMCWxL+4qSIxyWC5VuwYHvMFKjY2OyYAH3ir2E4vjgfcfcYEoC1WhY rALbidznL3E+32IDXg441XhPtXHs8++pupQGJta0nbag6kw6e2MMmSmrGwfVh57iKkxr cnb0gApWJheFTMJ0u/rbrrf6QcQmJ3AB3j4UbmRhW3otxillpP41Yj1vaLv++nqjO1S1 HGz5aloL2lwI1hAYKQDFKPD4+SsrGsmTNi3JImJnbdoAm2BzXTdQ1A5FThcSFutyLbjx KALGHgThL1zop0jIvJYTDn6xQwLzYBfyL+k4DrkR1nt+R1wMvoUV0lWbDe5l381qoNCt McUg== X-Forwarded-Encrypted: i=1; AHgh+RpMOiLyxPz0KzegYtuhMqk/qedPV52/Jn87qhNf9ayJpvv3Q02Dxg0mAIGMbWvgxHdPYCAj9hIP4jkoHK0=@vger.kernel.org X-Gm-Message-State: AOJu0YzNSQaSyt3UMqCpLeikFtY5QDhBiQh8lRhZA2b+rDxC7hYiegqN TlVkJxWM8iz32LT95UOCqzZZRrLv5xwbPexG3nACorolx1YsEZrj/Yp7 X-Gm-Gg: AR+sD13PbdxMLMBfC3Lkb409sLrFE8l4klWiaQs37kM0+uCb1Fw1ST8PjgwOr9bHeJy 760QBXtN38K5s9bRGSGKMvZC+b/76f9bFlOMDipCpqOwLt5TD1CgnnMC9Ux1E7zCmIFovqcSo68 mO9qQhf4BMMCcTIQ0I2A+dVfUYgVgGSfrr+ctoHEMWDg5f4qCBkX9zObcUr4I20bCvP2IMCL4K7 ZMfNSTlvFf/Ob4HMpaoYtOzb3gVeIiup3e4GS48frc85LXF9c2sNGx1PJBYRcGrZT/AkUmZusMS BvX2hcNwcDCkX4eoUbb48dlmsZnvNd6unraF5s5oLlphhG7HHWbEM4nIPoKfDp8dg+1viHMK1DC 3xiScEU432kqdCGI8N+Bf6d5DRF7aopEGJ2YJwaNmfahdMfTm9lt1Fm0YDXmjbHTEQycJ X-Received: by 2002:a05:600c:4685:b0:493:f42e:1b3f with SMTP id 5b1f17b1804b1-4957ac0c193mr12294545e9.3.1784847460405; Thu, 23 Jul 2026 15:57:40 -0700 (PDT) Received: from skbuf ([2a02:2f04:d801:b100:9055:4669:600a:7f4d]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4957af6adbbsm24689205e9.6.2026.07.23.15.57.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jul 2026 15:57:39 -0700 (PDT) Date: Fri, 24 Jul 2026 01:57:35 +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: <20260723225735.b7muegd4dlc6wsxz@skbuf> References: <34a027de7d860796d37de2f2108337eb82110144.1784679091.git.daniel@makrotopia.org> 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: <34a027de7d860796d37de2f2108337eb82110144.1784679091.git.daniel@makrotopia.org> 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.