linux-kernel - RE: [PATCH v2 0/5] iommu/vt-d: Ensure memory ordering in context & root entry updates

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BN9PR11MB52766746A06B61D24198F9648C85A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Thu, 8 Jan 2026 02:22:23 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Dmytro Maluka <dmaluka@...omium.org>
CC: Jason Gunthorpe <jgg@...pe.ca>, David Woodhouse <dwmw2@...radead.org>, "Lu
 Baolu" <baolu.lu@...ux.intel.com>, "iommu@...ts.linux.dev"
	<iommu@...ts.linux.dev>, Joerg Roedel <joro@...tes.org>, Will Deacon
	<will@...nel.org>, Robin Murphy <robin.murphy@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Vineeth
 Pillai (Google)" <vineeth@...byteword.org>, Aashish Sharma
	<aashish@...hishsharma.net>, Grzegorz Jaszczyk <jaszczyk@...omium.org>,
	"Dong, Chuanxiao" <chuanxiao.dong@...el.com>
Subject: RE: [PATCH v2 0/5] iommu/vt-d: Ensure memory ordering in context &
 root entry updates

> From: Dmytro Maluka <dmaluka@...omium.org>
> Sent: Tuesday, January 6, 2026 10:40 PM
> 
> On Tue, Jan 06, 2026 at 07:48:50AM +0000, Tian, Kevin wrote:
> > yeah WRITE_ONCE() is not by definition to guarantee the ordering between
> > CPU and device.
> 
> Yes, WRITE_ONCE is not about HW guarantess at all, it is about compiler
> guarantess. And it is not about ordering, it is about compiler's
> guarantee to store the given 64-bit value once, with one instruction.
> But this compiler guarantee is exactly my point (see my last reply to
> Jason).
> 
> > lots of READ_ONCE()/WRITE_ONCE() in existing code are meaningless,
> > as 1) between CPUs there is already lock protection; 2) between CPU and
> > device it requires dma_wmb() to guarantee the order.
> 
> As I see it, those WRITE_ONCEs (maybe not READ_ONCEs) haven't been
> meaningless (I mean, they have been actually useful) so long as we
> haven't been using any barriers. Again, on x86, store ordering requires
> just compiler ordering, and dma_wmb() is just a compiler barrier. So,
> assuming this driver is only used on x86 (which is, well, true :)),
> we are lacking even compiler barriers, but at least we have those
> WRITE_ONCEs, which provide compiler ordering too (although only between
> each other, not with any other memory accesses, but that seems enough
> for our case).
> 
> And again, I agree it is not pretty to rely on arch-specific ordering
> assumptions, and doing in-place updates via those context_xxx() and
> pasid_xxx() helpers all over the place instead of updating whole entries
> seems a strange choice. But that is how it was implemented 10 or so
> years ago, and overhauling that hasn't been my goal.

sure. the point here is to align on what is the right thing to do. then
we could have short-term fixes plus bigger refactoring later.