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
