From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f171.google.com (mail-dy1-f171.google.com [74.125.82.171]) (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 6112B3AE70E for ; Wed, 25 Mar 2026 15:06:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774451192; cv=none; b=Yl+eQ67l6lsuisbFBVaTiZ5WyeX4w87Y+huaRDQfn16627DiVk4KxbgExAnPLaXjfaWGL2UEwA8RrHWS0tlMWOgzWv5+kEIu5L8fFsefNOJgKAxW6rtcTj1eJz0ZE1LYZX9fU1WKhh+EAx/YxuyC68O0Tr3gBZJIqvhqhOLT69k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774451192; c=relaxed/simple; bh=hueUun48O4250wdQs94dWOVmghwrQOiUb0g955DTCkk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=U586udyECuRa//7JDDNwbVtUM046znI6FIH/W1eguUKYdkIj+zjK0VKk9ufrnCUSVylyZrwA7DSKCvQBxLCbHspThc3El8eqQ+bMjoKqLO5hZi6VEtcFzlewviFfBrWNztimMi0hbOFxQIXDP5Tp6PGiuXkFhuzBlhZTcZF4g9w= 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=bxsBW043; arc=none smtp.client-ip=74.125.82.171 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="bxsBW043" Received: by mail-dy1-f171.google.com with SMTP id 5a478bee46e88-2c160308a54so932730eec.0 for ; Wed, 25 Mar 2026 08:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774451190; x=1775055990; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=/d4Gn1kS5MGurytQaHUUdFFZv/IQSTbByU+x/UA/BgI=; b=bxsBW043Y5w/Dz8Y7N/NIiibrY68N4RdaHozWOv+rAlIeRZyuQqI2cujs3ZfRtTMCc RCO+i4urjzpZM9YVvNvg6cbNOBhzrhgQcFqq3CrLCxR3IgjvqUcRIT5b8kIF403L0dcc 05XD9q5JXZ5kRRBn6vQrz65dzfz9pavFtAAHKGiBYlFkMsZpeRR1dvTUfY/QMEYoYqKx F2frc57Z8FHTlkTPdVhlzcwIu0/beNFkPhyYMJFNfqZq0qO2OTI2d9KFYnYFCsWUfCrG WO5HKQKePtf+5mhwrbLyOd+0aDHDhmsWogVgXOPCmo65kTvjM+FdYcqFdd8OKuxTUHbX wyCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774451190; x=1775055990; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/d4Gn1kS5MGurytQaHUUdFFZv/IQSTbByU+x/UA/BgI=; b=PUlx6xi84vy+NhIHlVRLd2sJEscO/wQ0F0ITjOAlU4UyttTPKZ+MFzQV4m0wrjs3bw TGR6qrFK20GhwATVAMDihTapL+h50rZFGw1iQGhyCQHhEGfDFEZs9Ws14qW2O3wx6Ykt U4AcfwOAyQfnXAzKYAeyoKxTXroJjVuU5I5FSFMQoN/q40HLz6AKbVlUfk/qR8I+KqUT n9Hz33RL0Dg5OcRpjWBIiJPgmlrCZRGuQ2j4DJim9fweVNpPRnxeR7JmbQmh4Xwx2sf7 DboqM1KELRuKpbu5qch3A2GMvfqTTUywbSgIAa+JBuxUH9Z1RzuEJX7xZYvR3sc1nUHl Rufw== X-Forwarded-Encrypted: i=1; AJvYcCVnZEJt8pC76ix8/ifToTTC8o1QA2rc16ps3fP8NgNh+jV8BsHPvDwFUG8FIzmaEOiSbu+9uGsRQJ4Hnok=@vger.kernel.org X-Gm-Message-State: AOJu0YwCA9YXxUWAcY7awZgHG7SXdrS2SCTemOgN4K4UF7sw3JqQ4i6Z erpN0WWYOIZhP1iG8FcGVINLfzasfyCXqCrA1VCzcL6iN0eiubpfHQc= X-Gm-Gg: ATEYQzzO2IsiWkJVzSue5p9TIafDwAaKGHfuZyOfNiLId0iN6tMU1KBEEabzpNvSiz8 58poO6kLXbF6hW0V3q96TyIhu2XnWycVqTPhsTKfm+cOSNv9eW/IlDyBUEOisi+A4yMybMqhK9/ +qqdh4ZHALH2LUF8G/tx2qj0xDW8qG2e7NRt2T4WH6bKduRkqzyacPZpcA5fX054izgNW9wwUO9 Y410AEHp2sO3EBPyL5BZlmuTXTjHGNwk8xW1prhK5S/b7WLIN3rCef8wNUQeu+Tbo/o2Qv3Scsw SMCW13hLVLfqW07HuPPrIknWH1QR1mVTiPHk0ouOMuEmEofIr/hpkBjBbJiThf2MN018SxKfwwp mEi573y93o1H98xAlLqlCYxpH0Tb/lyebopm2SbnpJOLm5eIk68QTWBcTTZaiT53WGrbYhHOP0R M0eVYtQszv42yoYF9s2HDwquHF5AtJKYmL8ht9e87nasbqXQwmNT+rGqBgKYlySFGdU7l5jR5j2 vpeAB88m9fMYYHHXQ== X-Received: by 2002:a05:7022:6984:b0:128:ca6f:adf0 with SMTP id a92af1059eb24-12a96e69cffmr1941893c88.17.1774451190214; Wed, 25 Mar 2026 08:06:30 -0700 (PDT) Received: from localhost (c-76-102-12-149.hsd1.ca.comcast.net. [76.102.12.149]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-12aa7248731sm29001c88.4.2026.03.25.08.06.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Mar 2026 08:06:29 -0700 (PDT) Date: Wed, 25 Mar 2026 08:06:28 -0700 From: Stanislav Fomichev To: Jakub Kicinski Cc: Stanislav Fomichev , netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, horms@kernel.org, corbet@lwn.net, skhan@linuxfoundation.org, andrew+netdev@lunn.ch, michael.chan@broadcom.com, pavan.chebbi@broadcom.com, anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com, saeedm@nvidia.com, tariqt@nvidia.com, mbloch@nvidia.com, alexanderduyck@fb.com, kernel-team@meta.com, johannes@sipsolutions.net, sd@queasysnail.net, jianbol@nvidia.com, dtatulea@nvidia.com, mohsin.bashr@gmail.com, jacob.e.keller@intel.com, willemb@google.com, skhawaja@google.com, bestswngs@gmail.com, aleksandr.loktionov@intel.com, kees@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, intel-wired-lan@lists.osuosl.org, linux-rdma@vger.kernel.org, linux-wireless@vger.kernel.org, linux-kselftest@vger.kernel.org, leon@kernel.org Subject: Re: [PATCH net-next v3 03/13] net: introduce ndo_set_rx_mode_async and dev_rx_mode_work Message-ID: Mail-Followup-To: Stanislav Fomichev , Jakub Kicinski , Stanislav Fomichev , netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, horms@kernel.org, corbet@lwn.net, skhan@linuxfoundation.org, andrew+netdev@lunn.ch, michael.chan@broadcom.com, pavan.chebbi@broadcom.com, anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com, saeedm@nvidia.com, tariqt@nvidia.com, mbloch@nvidia.com, alexanderduyck@fb.com, kernel-team@meta.com, johannes@sipsolutions.net, sd@queasysnail.net, jianbol@nvidia.com, dtatulea@nvidia.com, mohsin.bashr@gmail.com, jacob.e.keller@intel.com, willemb@google.com, skhawaja@google.com, bestswngs@gmail.com, aleksandr.loktionov@intel.com, kees@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, intel-wired-lan@lists.osuosl.org, linux-rdma@vger.kernel.org, linux-wireless@vger.kernel.org, linux-kselftest@vger.kernel.org, leon@kernel.org References: <20260320012501.2033548-1-sdf@fomichev.me> <20260320012501.2033548-4-sdf@fomichev.me> <20260323162003.0d155055@kernel.org> <20260324142114.216fcb01@kernel.org> <20260324204440.1752423d@kernel.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=utf-8 Content-Disposition: inline In-Reply-To: <20260324204440.1752423d@kernel.org> On 03/24, Jakub Kicinski wrote: > On Tue, 24 Mar 2026 15:49:27 -0700 Stanislav Fomichev wrote: > > > > Not sure why cancel+release, maybe you're thinking about the unregister > > > > path? This is rtnl_unlock -> netdev_run_todo -> __rtnl_unlock + some > > > > extras. > > > > > > > > And the flush is here to plumb the addresses to the real devices > > > > before we return to the callers. Mostly because of the following > > > > things we have in the tests: > > > > > > > > # TEST: team cleanup mode lacp [FAIL] > > > > # macvlan unicast address not found on a slave > > > > > > > > Can you explain a bit more on the suggestion? > > > > > > Oh, I thought it's here for unregister! Feels like it'd be cleaner to > > > add the flush in dev_*c_add() and friends? How hard would it be to > > > identify the callers in atomic context? > > > > Not sure we can do it in dev_xc_add because it runs under rtnl :-( > > I currently do flush in netdev_run_todo because that's the place that > > doesn't hold rtnl. Otherwise flush will get stuck because the work > > handler grabs it... > > I was thinking of something a'la linkwatch. We can "steal" / "flush" > the pending work inline. I guess linkwatch is a major source of races > over the years... > > Does the macvlan + team problem still happens with the current > implementation minus the flush? We are only flushing once so only > pushing the addresses thru one layer of async callbacks. Yes, it does happen consistently when I remove the flush. It also happens with my internal v4, so I need to look again at what's going on. Not sure whether it's my internal regression or I was just sloppy/lucky (since you're correct in pointing out that we flush only once). Before I went down the workqueue route, I had a simple net_todo_list-like approach: `list_add_tail` on enqueue and `while(!list_empty) run_work()` on rtnl_unlock. This had a nice properly of tracking re-submissions (by checking whether the device's list_head is linked into the list or not) and it was relatively easy to do the recursive flush. Let me try get back to this approach and see whether it solves the flush? Not sure what wq buys us at this point.