On 12/5/24 11:41, Lorenzo Stoakes wrote: > Lightweight guard region support has been added to Linux 6.13, which adds > MADV_GUARD_INSTALL and MADV_GUARD_REMOVE flags to the madvise() system > call. Therefore, update the manpage for madvise() and describe these > operations. > > Reviewed-by: Jann Horn <jannh@xxxxxxxxxx> > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> > --- > v4: > * Reference function chapters as per Alejandro. > * Minor rewording as per Alejandro. > > v3: > * Don't describe SIGSEGV as a fatal signal as per Jann. > https://lore.kernel.org/all/20241202165829.72121-1-lorenzo.stoakes@xxxxxxxxxx > > v2: > * Updated to use semantic newlines as suggested by Alejandro. > * Avoided emboldening parens as suggested by Alejandro. > * One very minor grammatical fix. > https://lore.kernel.org/all/20241129155943.85215-1-lorenzo.stoakes@xxxxxxxxxx > > v1: > https://lore.kernel.org/all/20241129093205.8664-1-lorenzo.stoakes@xxxxxxxxxx > > man/man2/madvise.2 | 93 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 93 insertions(+) > > diff --git a/man/man2/madvise.2 b/man/man2/madvise.2 > index 4f2210ee2..7d682fa40 100644 > --- a/man/man2/madvise.2 > +++ b/man/man2/madvise.2 > @@ -676,6 +676,91 @@ or secret memory regions created using > Note that with > .BR MADV_POPULATE_WRITE , > the process can be killed at any moment when the system runs out of memory. > +.TP > +.BR MADV_GUARD_INSTALL " (since Linux 6.13)" > +Install a lightweight guard region into the range specified by > +.I addr > +and > +.IR size , > +causing any read or write in the range to result in a > +.B SIGSEGV > +signal being raised. > +.IP > +If the region maps memory pages they will be cleared as part of the operation, > +though if Hm this reads a bit ambiguous. One could read it as the memory pages are being cleared, but it's the page tables. > +.B MADV_GUARD_INSTALL > +is applied to regions containing pre-existing lightweight guard regions, > +they are left in place. > +.IP > +This operation is only supported for writable anonymous private mappings which > +have not been mlock'd. Not sure if "mlock'd" is the canonical term, I think I've seen "locked" used before, which I don't think it's great. Maybe Alejandro knows better. (there's also another "mlock'd" later in the patch)
