On Fri, Nov 29, 2024 at 07:13:22PM +0100, Jann Horn wrote: > On Fri, Nov 29, 2024 at 4:59 PM Lorenzo Stoakes > <lorenzo.stoakes@xxxxxxxxxx> 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. > [...] > > +.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 fatal > > +.B SIGSEGV > > +signal being raised. > > Single-word nitpick: Maybe remove the word "fatal"? > > I think the term "fatal signal" normally refers to a signal that is > guaranteed to terminate the task (that's how the signal handling code > uses the term, more or less); but a SIGSEGV caused by VM_FAULT_SIGSEGV > can AFAIK be handled by a userspace signal handler. > > SIGKILL is the one signal that is always fatal; the kernel can also > send other signals in an always-fatal way, like with force_fatal_sig() > or force_exit_sig(), but those are not used for VM_FAULT_SIGSEGV. > (Those functions are mostly for cases where we can't continue because > something is in an unsafe state, like if a signal return failed and > the register state might now be messed up.) I think there's a bit of a disconnect between the meaning of a fatal signal in userland and the kernel, from the kerne's perspective as per fatal_signal_pending(), it is, as you say, SIGKILL.
