[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250908175542.GB699673@ziepe.ca>
Date: Mon, 8 Sep 2025 14:55:42 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Steven Price <steven.price@....com>
Cc: Suzuki K Poulose <suzuki.poulose@....com>,
Catalin Marinas <catalin.marinas@....com>,
"Aneesh Kumar K.V" <aneesh.kumar@...nel.org>,
linux-kernel@...r.kernel.org, iommu@...ts.linux.dev,
linux-coco@...ts.linux.dev, will@...nel.org, maz@...nel.org,
tglx@...utronix.de, robin.murphy@....com, akpm@...ux-foundation.org
Subject: Re: [RFC PATCH] arm64: swiotlb: dma: its: Ensure shared buffers are
properly aligned
On Mon, Sep 08, 2025 at 04:39:13PM +0100, Steven Price wrote:
> guest_memfd provided a nice way around this - a dedicated allocator
> which doesn't allow mmap(). This meant we don't need to worry about user
> space handing protected memory into the kernel. It's now getting
> extended to support mmap() but only when shared, and there was a lot of
> discussion about how to ensure that there are no mmap regions when
> converting memory back to private.
Yes, you probably have to loose mmap() support in this scenario unless
the kernel has lot more work to make things like O_DIRECT aware of
this sub-page safety requirement.
But, IMHO, this is an optimization argument. Unaligned smaller buffers
can memory copy in the VMM using read/write on the memfd. That is safe
on ARM.
I think the need should be made clear in the commit message what the
issue is. As I see it:
1) The RMM may have a 64K S2 or something else and just cannot do
shared/private at all using 4k
2) The hypervisor wants mmap() of 64K pages to support O_DIRECT.
Kernel cannot safely support O_DIRECT on partially GPT protected
64k pages. If userspace tricks the kernel into accessing something
GPT protected we cannot handle the kernel fault.
Therefor, the VM has to align shared/private pools to some size
specified by the hypervisor that accommodates 1 and 2 above.
Jason
Powered by blists - more mailing lists