From: Oleg Nesterov > Sent: 24 May 2019 14:29 > It seems that we all are just trying to confuse each other. I got lost. I'm always lost :-) > On 05/23, David Laight wrote: > > > > From: Oleg Nesterov > > > Sent: 23 May 2019 17:36 > > > On 05/23, David Laight wrote: > > > > > > > > From: Oleg Nesterov > > > > > On 05/23, David Laight wrote: > > ... > > > > > Not sure I understand... OK, suppose that you do > > > > > > > > > > block-all-signals; > > > > > ret = pselect(..., sigmask(SIG_URG)); > > > > > > > > > > if it returns success/timeout then the handler for SIG_URG should not be called? > > > > > > > > Ugg... > > > > Posix probably allows the signal handler be called at the point the event > > > > happens rather than being deferred until the system call completes. > > > > Queueing up the signal handler to be run at a later time (syscall exit) > > > > certainly makes sense. > > > > Definitely safest to call the signal handler even if success/timeout > > > > is returned. > > > > > > Why? > > > > > > > pselect() exists to stop the entry race, not the exit one. > > > > > > pselect() has to block SIG_URG again before it returns to user-mode, right? > > > > Yep. > > So the signal handler can't be called for a signal that happens after > > pselect() returns. > > Yes. And "after pselect() returns" actually means "after pselect() restores > the old sigmask while it returns to user mode". > > > > Suppose pselect() finds a ready fd, and this races with SIG_URG. > > > > You mean if SIG_URG is raised after a ready fd is found (or even timeout)? > > So the return value isn't EINTR. > > Yes. > > > (If an fd is readable on entry, the SIG_URG could have happened much earlier.) > > Why not? See the pseudo code above. It was blocked before pselect() was called. > So SIG_URG can be already pending when pselect() is called but since an fd is > already ready on entry pselect() restores the old sigmask (and thus blocks SIG_URG > again) and returns success. The handler is not called. > > However, if there is no a ready fd, pselect won't block. It will notice SIG_URG, > deliver this signal, and return -EINTR. To my mind changing the signal mask should be enough to get a masked signal handler called - even if the mask is reset before the syscall exits. There shouldn't be any need for an interruptible wait to be interrupted. I suspect that if you send a signal to a process that is looping in userspace (on a different) the signal handler is called on the next exit to userspace regardless as to whether the kernel blocks. epoll and pselect shouldn't be any different. Having the signal unmasked at any time should be enough to get it called. ... > > > What if SIG_URG comes right after pselect() blocks SIG_URG again? I mean, > > > how this differs the case when it comes before, but a ready fd was already > > > found? > > > > I suspect you need to defer the re-instatement of the original mask > > to the code that calls the signal handlers (which probably should > > be called with the programs signal mask). > > This is what the kernel does when the signal is delivered, the original mask > is restored after the signal handler runs. I'd have thought that the original signal mask (all blocked in the examples) should be restored before the signal handler is called. After all the signal handler is allowed to modify the processes signal mask. I've had horrid thoughts about SIG_SUSPEND :-) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
