Re: [PATCH v16 07/45] arm64: mm: Handle Granule Protection Faults (GPFs)

On Thu, Aug 13, 2026 at 11:11:03AM +0100, Will Deacon wrote:

On Wed, Aug 12, 2026 at 02:51:29PM +0100, Catalin Marinas wrote:

quoted

On Wed, Aug 12, 2026 at 06:12:09PM +0530, Pavan Kondeti wrote:

quoted

There is a valid case for fixup_exception() to be needed here in GPF
handling.

-000 |load_unaligned_zeropad(inline)
-000 |hash_name(inline)
-000 |link_path_walk()
-001 |path_lookupat()
-002 |filename_lookup()
-003 |vfs_statx()
-004 |vfs_fstatat()

We observed this in Android running Gunyah when the page is mapped in
EL1 but unmapped at EL2. path_lookupat() can actually handle this
via fixup_exeption() when a word load crosses the page boundary.
However, Gunyah injects a Synchronous External Abort and we have
a downstream patch [1] that adds fixup_exception() in do_sea(). pKVM
injects [2] such faults back to EL1 and fixup_exception() is taken care.

Ah, good point, completely forgot about load_unaligned_zeropad(). Since
we don't unmap the linear map for delegated pages, we'll need the
fixup_exception(). And I guess warning in this case is not desirable
either. We could limit it to EX_TYPE_KACCESS_ERR_ZERO and
EX_TYPE_LOAD_UNALIGNED_ZEROPAD, though not sure it's worth it.

Alternatively, I think the series to unmap guest memory from the linear
map would solve that for gmem:

https://lore.kernel.org/all/20260410151746.61150-1-kalyazin@amazon.com/ (local)

Thanks Will for sharing this information.

There are use cases outside gmem like FF-A lend to Secure Partition.
we may not be enforcing all such memory to be unmapped at EL1, correct?

Thanks,
Pavan