Re: signals: Bug or manpage inconsistency?

Thomas Gleixner writes: > While trying to address the longstanding FIXME in the posix timer code > related to ignored signals, I stumbled over the following issue: > > I blocked the signal of the timer, then installed the SIG_IGN handler, > created and started the timer.

Re: signals: Bug or manpage inconsistency?

Thomas Gleixner writes: > While trying to address the longstanding FIXME in the posix timer code > related to ignored signals, I stumbled over the following issue: > > I blocked the signal of the timer, then installed the SIG_IGN handler, > created and started the timer. After a short sleep the

Re: signals: Bug or manpage inconsistency?

Hi Thomas, On 05/30/2017 03:21 PM, Thomas Gleixner wrote: > While trying to address the longstanding FIXME in the posix timer code > related to ignored signals, I stumbled over the following issue: > > I blocked the signal of the timer, then installed the SIG_IGN handler, > created and started

Re: signals: Bug or manpage inconsistency?

Hi Thomas, On 05/30/2017 03:21 PM, Thomas Gleixner wrote: > While trying to address the longstanding FIXME in the posix timer code > related to ignored signals, I stumbled over the following issue: > > I blocked the signal of the timer, then installed the SIG_IGN handler, > created and started

Re: signals: Bug or manpage inconsistency?

ebied...@xmission.com (Eric W. Biederman) writes: > Thomas Gleixner writes: > >> On Tue, 30 May 2017, Linus Torvalds wrote: >>> On Tue, May 30, 2017 at 10:04 AM, Oleg Nesterov wrote: >>> > Obviously this is a user-visible change and it can break something.

Re: signals: Bug or manpage inconsistency?

ebied...@xmission.com (Eric W. Biederman) writes: > Thomas Gleixner writes: > >> On Tue, 30 May 2017, Linus Torvalds wrote: >>> On Tue, May 30, 2017 at 10:04 AM, Oleg Nesterov wrote: >>> > Obviously this is a user-visible change and it can break something. Say, >>> > an >>> > application does

Re: signals: Bug or manpage inconsistency?

Thomas Gleixner writes: > On Tue, 30 May 2017, Linus Torvalds wrote: >> On Tue, May 30, 2017 at 10:04 AM, Oleg Nesterov wrote: >> > Obviously this is a user-visible change and it can break something. Say, an >> > application does sigwaitinfo(SIGCHLD) and

Re: signals: Bug or manpage inconsistency?

Thomas Gleixner writes: > On Tue, 30 May 2017, Linus Torvalds wrote: >> On Tue, May 30, 2017 at 10:04 AM, Oleg Nesterov wrote: >> > Obviously this is a user-visible change and it can break something. Say, an >> > application does sigwaitinfo(SIGCHLD) and SIGCHLD is ignored (SIG_IGN), >> > this

Re: signals: Bug or manpage inconsistency?

On Tue, 30 May 2017, Linus Torvalds wrote: > On Tue, May 30, 2017 at 12:35 PM, Thomas Gleixner wrote: > > The reason why I'm looking into that is the silly case with posix interval > > timers dealing with ignored signals. We have to keep these timers self > > rearming because

Re: signals: Bug or manpage inconsistency?

On Tue, 30 May 2017, Linus Torvalds wrote: > On Tue, May 30, 2017 at 12:35 PM, Thomas Gleixner wrote: > > The reason why I'm looking into that is the silly case with posix interval > > timers dealing with ignored signals. We have to keep these timers self > > rearming because nothing rearms them

Re: signals: Bug or manpage inconsistency?

On Tue, 30 May 2017, Linus Torvalds wrote: > On Tue, May 30, 2017 at 10:04 AM, Oleg Nesterov wrote: > > Obviously this is a user-visible change and it can break something. Say, an > > application does sigwaitinfo(SIGCHLD) and SIGCHLD is ignored (SIG_IGN), this > > will no longer

Re: signals: Bug or manpage inconsistency?

On Tue, 30 May 2017, Linus Torvalds wrote: > On Tue, May 30, 2017 at 10:04 AM, Oleg Nesterov wrote: > > Obviously this is a user-visible change and it can break something. Say, an > > application does sigwaitinfo(SIGCHLD) and SIGCHLD is ignored (SIG_IGN), this > > will no longer work. > > That's

Re: signals: Bug or manpage inconsistency?

On Tue, May 30, 2017 at 12:35 PM, Thomas Gleixner wrote: > Right, blocking signals which are not set to SIG_IGN makes perfectly sense. > The > SIG_IGN case is what bothers me. The thing is, the SIG_IGN may not *remain* a SIG_IGN. Put another way, let's say that you are a

Re: signals: Bug or manpage inconsistency?

On Tue, May 30, 2017 at 12:35 PM, Thomas Gleixner wrote: > Right, blocking signals which are not set to SIG_IGN makes perfectly sense. > The > SIG_IGN case is what bothers me. The thing is, the SIG_IGN may not *remain* a SIG_IGN. Put another way, let's say that you are a process that uses

Re: signals: Bug or manpage inconsistency?

On Tue, 30 May 2017, Linus Torvalds wrote: > On Tue, May 30, 2017 at 6:21 AM, Thomas Gleixner wrote: > > > > Linus, any recollection? > > > > IMO, it's perfectly reasonable to discard ignored signals even when the > > signal is in the blocked mask. When its unblocked and

Re: signals: Bug or manpage inconsistency?

On Tue, 30 May 2017, Linus Torvalds wrote: > On Tue, May 30, 2017 at 6:21 AM, Thomas Gleixner wrote: > > > > Linus, any recollection? > > > > IMO, it's perfectly reasonable to discard ignored signals even when the > > signal is in the blocked mask. When its unblocked and SIG_IGN is replaced > >

Re: signals: Bug or manpage inconsistency?

On 05/30, Linus Torvalds wrote: > > On Tue, May 30, 2017 at 10:04 AM, Oleg Nesterov wrote: > > > > I can't comment, I never tried to understand the rationality behind the > > current > > behaviour. But at least the sending path should never drop a blocked SIG_DFL > > signal,

Re: signals: Bug or manpage inconsistency?

On 05/30, Linus Torvalds wrote: > > On Tue, May 30, 2017 at 10:04 AM, Oleg Nesterov wrote: > > > > I can't comment, I never tried to understand the rationality behind the > > current > > behaviour. But at least the sending path should never drop a blocked SIG_DFL > > signal, there is no other

Re: signals: Bug or manpage inconsistency?

On Tue, May 30, 2017 at 10:04 AM, Oleg Nesterov wrote: > > I can't comment, I never tried to understand the rationality behind the > current > behaviour. But at least the sending path should never drop a blocked SIG_DFL > signal, there is no other way to ensure you won't miss a

Re: signals: Bug or manpage inconsistency?

On Tue, May 30, 2017 at 10:04 AM, Oleg Nesterov wrote: > > I can't comment, I never tried to understand the rationality behind the > current > behaviour. But at least the sending path should never drop a blocked SIG_DFL > signal, there is no other way to ensure you won't miss a signal during

Re: signals: Bug or manpage inconsistency?

On 05/30, Thomas Gleixner wrote: > > So I found at least some explanation by studying the spec some more. > > There are two variants of ignored signals: > > 1) handler is SIG_IGN > > 2) handler is SIG_DFL and default action is 'ignore' Yes, and note that sys_rt_sigaction() discard the pending

Re: signals: Bug or manpage inconsistency?

On 05/30, Thomas Gleixner wrote: > > So I found at least some explanation by studying the spec some more. > > There are two variants of ignored signals: > > 1) handler is SIG_IGN > > 2) handler is SIG_DFL and default action is 'ignore' Yes, and note that sys_rt_sigaction() discard the pending

Re: signals: Bug or manpage inconsistency?

On Tue, May 30, 2017 at 6:21 AM, Thomas Gleixner wrote: > > Linus, any recollection? > > IMO, it's perfectly reasonable to discard ignored signals even when the > signal is in the blocked mask. When its unblocked and SIG_IGN is replaced > then the next signal will be

Re: signals: Bug or manpage inconsistency?

On Tue, May 30, 2017 at 6:21 AM, Thomas Gleixner wrote: > > Linus, any recollection? > > IMO, it's perfectly reasonable to discard ignored signals even when the > signal is in the blocked mask. When its unblocked and SIG_IGN is replaced > then the next signal will be delivered. But hell knows,

Re: signals: Bug or manpage inconsistency?

On Tue, 30 May 2017, Thomas Gleixner wrote: > The commit which added the queuing of blocked and ignored signals is in the > history tree with a pretty useless changelog. > > https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git > > commit 98fc8ab9e74389e0c7001052597f61336dc62833 >

Re: signals: Bug or manpage inconsistency?

On Tue, 30 May 2017, Thomas Gleixner wrote: > The commit which added the queuing of blocked and ignored signals is in the > history tree with a pretty useless changelog. > > https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git > > commit 98fc8ab9e74389e0c7001052597f61336dc62833 >

signals: Bug or manpage inconsistency?

While trying to address the longstanding FIXME in the posix timer code related to ignored signals, I stumbled over the following issue: I blocked the signal of the timer, then installed the SIG_IGN handler, created and started the timer. After a short sleep the timer has fired several times, but

signals: Bug or manpage inconsistency?

While trying to address the longstanding FIXME in the posix timer code related to ignored signals, I stumbled over the following issue: I blocked the signal of the timer, then installed the SIG_IGN handler, created and started the timer. After a short sleep the timer has fired several times, but