From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f45.google.com (mail-yx1-f45.google.com [74.125.224.45]) (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 717953D5251 for ; Wed, 25 Feb 2026 15:14:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772032491; cv=none; b=QsS3pPMB80osW+/BpK6rHDVPcB4gBLI1/obxvIYXU4W/x+ryqsYLBBnM0DnRsJPQ+x11ojVFoEja+0ny1LzGkehQLO181VrQSPYLGZEELt3a70Xwn9tnEhA+cU5pGTVKyIfHq7GQdSXHeUi+/Ij4eSL/5peBgNwIop9atiP4f/4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772032491; c=relaxed/simple; bh=VfLwbQTWRqJ9p2z5oBuHtvnwEkZsPqYdX41RY6Y6XYs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fMmfyXUt52azeQ4NjQ3JWRwb5boLfsM9Wwhj67Z+9U/kbsuQJHswhfThHho6d5DvfRxYyxaRVKKlVINFC/gChoKCVZZ+q4M2MOwYdmL0/0duICuxRGwu8JMLJ0GmzRS9nkKAcXvr67cf2b5KbbHr0jX0JvqrCrxfbY4mG5BnWY0= 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=LvuIoCM7; arc=none smtp.client-ip=74.125.224.45 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="LvuIoCM7" Received: by mail-yx1-f45.google.com with SMTP id 956f58d0204a3-64ada2c30a1so5885101d50.0 for ; Wed, 25 Feb 2026 07:14:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772032489; x=1772637289; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=6WNBbOPPM7eifFdwJBPvZW84/lfztyEzVfKEidDFiDc=; b=LvuIoCM7/OEWHB85aLEodTlIVWbURk7fcC1OYTKBhBMiSDoL8osvCS8G7A60gMBd2a F6TMvOEYK7TT0SAKVLp7tZ9xTuCjJoERv/mFMkM+pIynyCNZ7tkTDlUr8kYgaV/vYQtu errLFsZVaF5DAlda9nsBAgJLcEDsGnG89KzEmp5YQZj/HvFE5bHR7Y1Jnl1eyz2L6yLa kJqfIIJumUNUNs5XmHOT4kVT9atu4jgnecNZghw7yTKs1VhuqkBDPUiSnMsA9i8NYUA0 A0Hh7A0qiMXSUhFwUUaCTbUUyR+UL/o1lbThc/b9LgNMFdp58idP6GRdIg4REZ74Ec1k Mdkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772032489; x=1772637289; h=in-reply-to:content-disposition: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; bh=6WNBbOPPM7eifFdwJBPvZW84/lfztyEzVfKEidDFiDc=; b=tc/TJ7b+tbGhR9aaqvPHIbZqdJ1aCpPYSS9STe5mv/7VQLWtMmEnP14F3nh/iHHh8P dyD7vdrrnHOFNLmFsgtwkL62uHydH5GQoLmyWUY7LZrxvgsa52vW5o61fcHNKbiXZT+L dLZmLjBhZhWCA7fubJqptTJm8IFViMLrpsCN6ZNIJGpZMMhAzZAHAxr5vIrMLpw6mMS7 I2EPIWYehttS+QrDtdWhxxcmZteXAXuCwjX5vjxTjSLTq+2BAFuGMuHomUZZhgLs7BYn J0OsHCriCa8PeNTwaqNri+2FP5kZh0DTDxhWAmJlA/oKRtvge/HC08ZhtwSPEZKKcElP ehIw== X-Forwarded-Encrypted: i=1; AJvYcCXe80keVQ0ck0slQB7r37kLBU+22cD2AQ0jCqv6nG0QIsBSCcq3pOtB1RvkKDYVRIDMu9fu81Toc+8GvPk=@vger.kernel.org X-Gm-Message-State: AOJu0YwVlrTMHMC/ipnp/KENPCiY5B88ZnfNkKdelbfBi2Gl9SdJVy/P W1yH2lDbfrTTQZ9m9ARhAkSkjJ5/e+uzyLgXG6/cVgZAX80trjFT0sm5 X-Gm-Gg: ATEYQzws9zhpUtJu2zFuQlSPeIBIBVfWUj1LQ4obFR2i/3F/ROlqwvylKiK9BZd99td SAPDQlwGhlDaFTNQfMORMcBmviX+Oa71PfwIRh6e9rzZ5eJ6rEKIyLuOskW59DYXr7f70yqHUHI 7p/W1O3xXiHuTPy11pRzJrcjtY5JoyNWkK1arC7F/8d1jBBdMqjlAHQBegTfP3AXGXoK4Tc0s4O cDnXJL1sjDocBu6yL1clEN9MZWIcrWnzuiaamfsx6Fpl5fZ0d3+KfZYjCgID+pkotTegSh4hofF q/VmNMizxdEC/+lab5UTP52N6HceGETpjOZk8s9OSiwt1pmOmep0YKQtRoI54rDPiMzrJy7y206 0rr/4i1xjBpNpbw0IZ+dhmedx5G+9FTRXvUJ7Op8XRo8ICftkTCX2YXsbrU5RNstM9ei2lRKjNA cHqODHy5HS1M05RsMEgHUlf6pREZK8SBRnZABw0LiEH7URqhMAnvDmlB6L4A== X-Received: by 2002:a05:690e:b8a:b0:64c:9aa3:b0cb with SMTP id 956f58d0204a3-64c9aa3b14fmr5357466d50.14.1772032489206; Wed, 25 Feb 2026 07:14:49 -0800 (PST) Received: from devvm11784.nha0.facebook.com ([2a03:2880:25ff:72::]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-64c7a37abafsm5618712d50.16.2026.02.25.07.14.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Feb 2026 07:14:48 -0800 (PST) Date: Wed, 25 Feb 2026 07:14:46 -0800 From: Bobby Eshleman To: Stanislav Fomichev Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Mina Almasry , Kaiyuan Zhang , Stanislav Fomichev , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Bobby Eshleman Subject: Re: [PATCH net] net: devmem: use READ_ONCE/WRITE_ONCE on binding->dev Message-ID: References: <20260223-devmem-membar-fix-v1-1-37dcae1e49f8@meta.com> 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: On Tue, Feb 24, 2026 at 05:49:42PM -0800, Stanislav Fomichev wrote: > On 02/23, Bobby Eshleman wrote: > > From: Bobby Eshleman > > > > binding->dev is protected on the write-side in > > mp_dmabuf_devmem_uninstall() against concurrent writes, but due to the > > concurrent bare read in net_devmem_get_binding() it should be wrapped in > > a READ_ONCE/WRITE_ONCE pair to make sure no compiler optimizations play > > with the underlying register in unforeseen ways. > > > > Fixes: bd61848900bf ("net: devmem: Implement TX path") > > Signed-off-by: Bobby Eshleman > > --- > > Note1: This didn't crop up in a discrete error, but just something that > > didn't seem to quite follow my understanding of memory-barriers.txt, as > > frail and feeble as that understanding may be. > > > > Note2: the "Fixes" commit I referenced is the first one to introduce > > binding->dev bare accesses, but the later patch '6a2108c78069 ("net: > > devmem: refresh devmem TX dst in case of route invalidation")' carried > > that forward. I wasn't sure which was the ideal one to select for the > > "Fixes" label. > > --- > > net/core/devmem.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/net/core/devmem.c b/net/core/devmem.c > > index 63f093f7d2b2..cb989949d43c 100644 > > --- a/net/core/devmem.c > > +++ b/net/core/devmem.c > > @@ -398,7 +398,8 @@ struct net_devmem_dmabuf_binding *net_devmem_get_binding(struct sock *sk, > > * net_device. > > */ > > dst_dev = dst_dev_rcu(dst); > > - if (unlikely(!dst_dev) || unlikely(dst_dev != binding->dev)) { > > + if (unlikely(!dst_dev) || > > + unlikely(dst_dev != READ_ONCE(binding->dev))) { > > err = -ENODEV; > > goto out_unlock; > > } > > What about the other similar check in validate_xmit_unreadable_skb? > > I don't have a strong opinion, but it feels like as long as we are not > using these ->dev pointers (and we are only using them for comparisons), > we should be fine (plus, memory tearing for u64 is not something that > can happen?). Makes sense. I don't think it presents a current problem, its just defensive (e.g., someday other functions referencing binding->dev get inlined here and the compiler does load omission or invented loads). I didn't know about u64 being immune to memory tearing. If it doesn't look like an issue to anyone else, I'll not try to push on this. Best, Bobby