Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1305159 > unrolled thread

Re: [PATCH] um: Fix get_signal() usage

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] um: Fix get_signal() usage Al Viro <viro@ZenIV.linux.org.uk> - 2016-01-09 05:00 +0100
    Re: [PATCH] um: Fix get_signal() usage Al Viro <viro@ZenIV.linux.org.uk> - 2016-01-09 05:20 +0100
    Re: [PATCH] um: Fix get_signal() usage Richard Weinberger <richard@nod.at> - 2016-01-09 11:00 +0100

#1305159 — Re: [PATCH] um: Fix get_signal() usage

On Wed, Nov 18, 2015 at 09:51:43AM +0100, Richard Weinberger wrote:
> If get_signal() returns us a signal to post
> we must not call it again, otherwise the already
> posted signal will be overridden.
> Before commit a610d6e672d this was the case as we stopped
> the while after a successful handle_signal().

Old behaviour had been wrong.  If you have several pending signals,
more than one sigframe should be built, as if the second, etc. had
been delivered right on the entry into the handler.

Stopping after the first one is obviously wrong - consider the case
when attempt to deliver it has raised SIGSEGV.

[toc] | [next] | [standalone]

#1305163

On Sat, Jan 09, 2016 at 03:51:25AM +0000, Al Viro wrote:
> On Wed, Nov 18, 2015 at 09:51:43AM +0100, Richard Weinberger wrote:
> > If get_signal() returns us a signal to post
> > we must not call it again, otherwise the already
> > posted signal will be overridden.
> > Before commit a610d6e672d this was the case as we stopped
> > the while after a successful handle_signal().
> 
> Old behaviour had been wrong.  If you have several pending signals,
> more than one sigframe should be built, as if the second, etc. had
> been delivered right on the entry into the handler.
> 
> Stopping after the first one is obviously wrong - consider the case
> when attempt to deliver it has raised SIGSEGV.

Note that subsequent signals do *not* override the register values set by
the first one - copy_sc_to_user() will store them in the corresponding
sigframes, so that after you reach the end of the handler for your second
signal {rt_,}sigreturn() will land you in the beginning of the first one.

Check how native x86 behaves - set a couple of handlers, block them with
sigprocmask(), raise both signals and unblock them.  Then have the
handlers examine and dump their struct ucontext (pointed to by the third
argument of handler).  You'll see that the first one to be executed will
have uc->uc_mcontext.ip pointing to the other handler and uc->uc_mcontext.ax
containing the other signal number.

[toc] | [prev] | [next] | [standalone]

#1305198

Am 09.01.2016 um 04:51 schrieb Al Viro:
> On Wed, Nov 18, 2015 at 09:51:43AM +0100, Richard Weinberger wrote:
>> If get_signal() returns us a signal to post
>> we must not call it again, otherwise the already
>> posted signal will be overridden.
>> Before commit a610d6e672d this was the case as we stopped
>> the while after a successful handle_signal().
> 
> Old behaviour had been wrong.  If you have several pending signals,
> more than one sigframe should be built, as if the second, etc. had
> been delivered right on the entry into the handler.
> 
> Stopping after the first one is obviously wrong - consider the case
> when attempt to deliver it has raised SIGSEGV.

You are right. Thanks for pointing this out.
Will revert.

Thanks,
//richard

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web