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! :)
