On Sat, Sep 26, 2026 at 05:43:08PM +0530, Sumit Garg wrote:
Looks like you dropped me from your reply.
Huh, that's weird. If I hit reply-all ('g') in mutt, it moves the entire CC list to To: and drops you. I suspect the same thing happened to Thierry when he replied here:
https://lore.kernel.org/all/arJcN60nagFKXj2Q@orome/
I can't figure out why that's happening :/ I manually tried to fix the To: and Cc: lines in this message.
On Tue, 22 Sep 2026 at 15:55:59 +0100, Will Deacon wrote:
I spoke to Brendan at LPC (?) last year but this doesn't really work for arm64 because it relies on being able to unmap arbitrary parts of the linear map, which isn't generally possible unless you force pte-level mappings for everything, which is prohibitive for perf/power.
As per the cover letter it's about allocating pages that are not present in the direct map. This essentially fits the protected DMABufs use-case where we don't want any kernel mapping to exist at any time. Bufers allocated from protected DMABufs are only meant to be accessed by the TEE implementation or HW accelerators like in the secure media pipeline.
That sounds like it should probably build on top of this series, then. You could allocate the DMABufs from a CMA region that has no linear alias.
Vincent's series tackles that by using a pool so that only that part of memory requires the pte-level mappings in the linear map. That's the whole point of it, so I don't think it makes sense to drop it in favour of Brendan's approach (which doesn't work).
For protected DMABufs, we even don't require any pte-level mappings in linear map. The whole idea of mapping and unmapping is just a bottleneck for performance sensitive secure media pipeline use-cases. That's why if we can support __GFP_UNMAPPED with the memory allocator on arm64 would be the best fit for this use-case.
The point is that you will require pte-level mappings for the linear map if you want to unmap from it at runtime on arm64. If you don't, then you can end up needing to split a block mapping (e.g. pmd-level) when you decide to unmap only part of it and there isn't a safe way to do that on arm64 without transiently unmapping the entire block, which can lead to fatal translation faults during that window.
Now the question is why arm64 can't support __GFP_UNMAPPED similar to how Brendan is doing it for x86?
Because arm64 != x86? Presumably x86 doesn't have the strict break-before-make requirements we have on arm64.
Will