From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f45.google.com (mail-dl1-f45.google.com [74.125.82.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 77D7F1D5ABA for ; Wed, 25 Feb 2026 01:49:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771984185; cv=none; b=rWFYTokdJQODHsrlCi5tOhoJ6P3ZqLPhPK+4qJZzA+X3RyMvuHQfKhpXATWazdbC16SkcfOWTnfB9n68cn5N3Fh8mLZ3pIgIzDIjPfy8Z9LIhEmH1PHKjKdOyhuQMQPRA5a+NAgJvbho1/QrDXtv1TiaKcxmejnaWa1QlCPOMd0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771984185; c=relaxed/simple; bh=UnvMTmqzgD2ANWMjeTsjYqnnQaamppxc4Fn/oLiJKq4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bLcajFgNTotJqppumL4kvDuyDdHzTHIKJsBat6chLNLbTo/Vj71SCKAC7xkaAvbLL8Yf6bP2mErDqm1KSoHqG3VeptT/dCQiLqwJLQ1yWrjJ4x8ur7iimaCKrgNxSpDZxQlOvBHGFyEP27L+t+VOkMkYqrFLDI8Tub8hCPOy7Zg= 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=iQdH/H/q; arc=none smtp.client-ip=74.125.82.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="iQdH/H/q" Received: by mail-dl1-f45.google.com with SMTP id a92af1059eb24-126ea4b77adso7601260c88.1 for ; Tue, 24 Feb 2026 17:49:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771984183; x=1772588983; 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=oUK1ogXqhyxce3y3aAcPvYgkr3Cbva04wd5JBw1uJzo=; b=iQdH/H/qYwNO2wASKQKQ0ywRO6J/uwTFWonirAAvyo84p4DFtSBsaLw+1vGslhoVb0 YNhIIynPxvFfKSD7K+b2z0EtJcgLgWbPyJeMVPvrHZyuHsx8T83ZrNg8NTfooJnn2mhh vNboLhKpv6JYXf/5lhDnriS54auJ/g1eOkejTiNtvfGOaxZuu9u5HmsIDnwQNOTLNBOv KabwkyY5b8tVVICTkRFoxncYgG/c18uzUDy93w4Bs06M9V0ao6zDLVmRapU0lIcnXd/b V3V+SPk93mkep8RdLcX6ycT2iH5nOafOwIsLDO1QH4lxCc1dyJlJ1/BbxKCbDaViHEMr LxGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771984183; x=1772588983; 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=oUK1ogXqhyxce3y3aAcPvYgkr3Cbva04wd5JBw1uJzo=; b=vx7mpiKI57Ku2xBs9obNqz/V4SmW1Z6WAmOK1JXwVYezU09weIVU917q4EsPt5JJZd YUow8rd7F/KDvtbPXFt4VgzLeAjlyP12RfXIeHpZ7jRn3iyxzCOJp3qSLZDtxW+ovXCo nOkgyuVeLhm8X1TEHbMtGV9l6s8HbJTnriQXE9/sAlXZHZZvxXiL+dj+hM7x92ixCP7P R3hp4froTL7Rh1esIhicAoVNhIUIyfNsidgO2DCf3SlBw5Mv7N/VvMEdZI/6n02UbDkL lkNgFOEnkDx2zz1kcJv4vb4WCA7GipRIAQlSJY3UN2/xm1FRl8RaMfEcQlXr6Pg9fnkW TmcA== X-Forwarded-Encrypted: i=1; AJvYcCVIdmkyVy2ZV/6Os/jwaiB7knADuxFQtmb8X+O8GLOOcMaBn5SUxnb9NDZLKaxqhxFrDxm1Nn3bonMxDb0=@vger.kernel.org X-Gm-Message-State: AOJu0YyiX9giYkQhZdwz6lutIjqE4berurU5dlcVe/peTWt/eyozDErj PakTNtkTvnQal2IuQdb5cygOHgjnMK66p4qs4OERKOgvb4z3KlVrWE8= X-Gm-Gg: ATEYQzzPi6laLB2OfSiWst7JiY9ZS/Iogo8/UgROOYohxO69SzFKkcx6gci7HyZuwWD XHetTQ03X+lT6LlGGQ7VOl0Pd71pNQlaK1Jr40VZYL4jTD4utBRSvYmgK9k3DJ69FeO0d4y0re6 ersEAKNHI42k9j/98VSQ6P7iyahEgvle5zOmUzjAA+FS0rFY5MD4daLgUpigUsxMAnmwIvsCfF+ imTDReXjBx53axNFDYL9hy0JgeFUgiAo2uR5zI7IJ2dP0LVA0QSzz/ma3Y0Ib/8byH4LG59BThf CXgtcy4f5FF/kBgRKvOScuG+2FmiGoLpg0LLKgUdVEWTveFa3f+ajEpaIGobzH8q5fKT/KgGFH+ wIzQ0ZyFpDmqjmG6mZQqSjxpLk//Dopc6sTs/wQ0XVhCYyqMQZ11QIWGZNAsm8jKAQW8jfICUTp OR3AF9oQ/BSet2YKd3MemDe5Sao54Zt/q0Oaz58D7OOcwaHmY/wVvXeP2tcTF5iRF2teNLkDOoa shD2EhZgdq8ePHdfQ== X-Received: by 2002:a05:7022:6b94:b0:127:5c3d:bd95 with SMTP id a92af1059eb24-1276ad32725mr5411784c88.32.1771984183281; Tue, 24 Feb 2026 17:49:43 -0800 (PST) Received: from localhost (c-76-102-12-149.hsd1.ca.comcast.net. [76.102.12.149]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-1276af102d9sm11140052c88.1.2026.02.24.17.49.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Feb 2026 17:49:42 -0800 (PST) Date: Tue, 24 Feb 2026 17:49:42 -0800 From: Stanislav Fomichev To: Bobby Eshleman 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=utf-8 Content-Disposition: inline In-Reply-To: <20260223-devmem-membar-fix-v1-1-37dcae1e49f8@meta.com> 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?).