Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Mon, Oct 25, 2021 at 9:58 PM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: >> >> Rereading this I think you might be misreading something. > > Gaah. Yes, indeed. > >> force_siginfo_to_task takes a sigdfl parameter which I am setting in >> force_fatal_signal. > > .. and I realized that the first time I read through it, but then when > I read through it due to Andy saying it worries him, I missed it and > thought the handler didn't get reset. > > So the patch is fine. Thank you. Andy is right that there is a race with sigaction changing the signal handler. To make complete_signal reliably recognize fatal signals is going to take a bit of work. None of it particularly hard but there are a lot of pieces that need to be changed carefully. Part of the problem is that recognizing fatal signals early started out as an optimization, and there remain places in complete_signal and prepare_signal that assume it is always possible to not recognize fatal signals early and let get_signal handle things. The coredump handling of it is the biggest challenge. Computing a destination thread with wants_signal in complete_signal before dealing with fatal signals (which don't care) means that wants_signal can cause the early recognition of fatal signals to fail. The entire blocked vs real_blocked set of signal masks are interesting. The current way those signal masks work does not appear to allow knowing when blocked is being overridden and blocked is stored in real_blocked. Something I think needs to be known if fatal signal are always going to be recognized early. Given that race it looks like it is important to make the guarantee that fatal signals are always recognized early. So the rest of the kernel can count on that property. But I aim to get this set of changes into linux-next first. As I don't anything will melt down if we leave that race for a bit longer. Eric
