On Tue, Feb 18, 2025 at 01:12:05PM +0100, Vlastimil Babka wrote:
On 2/13/25 19:16, Lorenzo Stoakes wrote:
The guard regions feature was initially implemented to support anonymous mappings only, excluding shmem.
This was done such as to introduce the feature carefully and incrementally and to be conservative when considering the various caveats and corner cases that are applicable to file-backed mappings but not to anonymous ones.
Now this feature has landed in 6.13, it is time to revisit this and to extend this functionality to file-backed and shmem mappings.
In order to make this maximally useful, and since one may map file-backed mappings read-only (for instance ELF images), we also remove the restriction on read-only mappings and permit the establishment of guard regions in any non-hugetlb, non-mlock()'d mapping.
Do you plan to address mlock later too? I guess somebody might find use for those. Is there some fundamental issue or just that we need to define some good semantics for corner cases? (i.e. if pages are already populated in the mlocked area, discarding them by replacing with guard pte's goes against that, so do we allow it or not?).
Yeah that's the fundamental issue with mlock, it does not interact with the zapping part of MADV_GUARD_INSTALL, and that is why we disallow it (but not so for MADV_GUARD_REMOVE, as if a VMA that contains guard regions is locked _afterwards_ there will be no zapping).
We could potentially expose an equivalent, as there are for other flags, a _LOCKED variant of the madvise() flag, like MADV_GUARD_INSTALL_LOCKED to make this explicit.
That is probably the most sensible option, if there is a need for this!
Otherwise nice discussion of all the potential issues here!
Thanks! :)