[PATCH v10 09/15] KVM: guest_memfd: Add flag to remove from direct map
David Hildenbrand (Arm)
david at kernel.org
Fri Mar 6 07:16:18 PST 2026
On 3/6/26 15:49, Nikita Kalyazin wrote:
>
>
> On 06/03/2026 14:22, David Hildenbrand (Arm) wrote:
>> [...]
>>
>>>
>>> Dave pointed earlier that the failures were possible [1]. Do you think
>>> we can document it better?
>>
>> I'm fine with checking that somewhere (to catch any future problems).
>>
>> Why not do the WARN_ON_ONCE() in folio_restore_direct_map()?
>>
>> Then, carefully document (in the new kerneldoc for
>> folio_restore_direct_map() etc) that folio_restore_direct_map() is only
>> allowed after a prior successful folio_zap_direct_map(), and add a
>> helpful comment above the WARN_ON_ONCE() in folio_restore_direct_map()
>> that we don't expect errors etc.
>
> My only concern about that is the assumptions we make in KVM may not
> apply to the general case and the WARN_ON_ONCE may become too
> restrictive compared to proper error handling in some (rare) cases. For
> example, is it possible for the folio to migrate in between?
Not without migration support. But then, migration would have to make
sure that the destination folio has the direct map removed. So I
wouldn't worry about that.
Once you return an error from folio_restore_direct_map(), you better
document when/why it happens and how the caller should handle it.
There is nothing existing callers could really do, so it's an
implementation detail of the
folio_zap_direct_map()/folio_restore_direct_map() functions to make sure
it keeps working.
If it ever fails, we'll have to figure out how to keep the interface
working.
You can document any restrictions regarding when
folio_zap_direct_map()/folio_restore_direct_map() is allowed to be used
in the kerneldoc.
--
Cheers,
David
More information about the linux-riscv
mailing list