Alexander Bluhm <[email protected]> wrote: > When I came up with this diff in 2017, it was not considered the > correct fix. Syncing file system and some UVM logic was changed. > This improved the situation, but never fixed it.
I guess this got started after my hibernate/unmount change? > @@ -842,10 +842,13 @@ trapsignal(struct proc *p, int signum, u > * generated by the kernel, be ignorable or blockable. > * If it is and we're not being traced, then just kill > * the process. > + * init(8) must live forever, it gets a SIGBUS when > + * syncing disks unmaps its program pages. Certainly don't say "syncing disks". A future reviewer might not read that as 'when this message is printed during halt', but consider it any other vfs_sync operation, including sync(2). Probably better to mention vfs_shutdown() specifically. Also, isn't this incorrect about having unmapped pages. I think what happens is it is prevented from backing a new mapping, because the storage is halted. Is this more correct? "After vfs_shutdown(9), init(8) may cannot receive signals because new code pages cannot be mapped against halted storage". > if ((pr->ps_flags & PS_TRACED) == 0 && > (sigprop[signum] & SA_KILL) && > - ((p->p_sigmask & mask) || (ps->ps_sigignore & mask))) > + ((p->p_sigmask & mask) || (ps->ps_sigignore & mask)) && > + pr->ps_pid != 1) > sigexit(p, signum); > ptsignal(p, signum, STHREAD); > } OK, so if the sigexit() doesn't happen, what happens to the process instead? The signal simply disappears? Doesn't this signal also disappear when vfs_shutdown hasn't been called? I worry about a weird change in the signal disposition for init. Maybe there is a global variable from vfs_subr.c we can add into the condition?
