[PATCH] um: Fix get_signal() usage

[PATCH] um: Fix get_signal() usage

[Richard Weinberger]

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().

Cc: <stable@vger.kernel.org> # 3.10-
Fixes: a610d6e672d ("pull clearing RESTORE_SIGMASK into block_sigmask()")
Signed-off-by: Richard Weinberger <richard@nod.at>
---
 arch/um/kernel/signal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/um/kernel/signal.c b/arch/um/kernel/signal.c
index 57acbd6..fc8be0e 100644
--- a/arch/um/kernel/signal.c
+++ b/arch/um/kernel/signal.c
@@ -69,7 +69,7 @@ void do_signal(struct pt_regs *regs)
 	struct ksignal ksig;
 	int handled_sig = 0;
 
-	while (get_signal(&ksig)) {
+	if (get_signal(&ksig)) {
 		handled_sig = 1;
 		/* Whee!  Actually deliver the signal.  */
 		handle_signal(&ksig, regs);
-- 
2.5.0

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

[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.

Re: [uml-devel] [PATCH] um: Fix get_signal() usage

[Al Viro]

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.

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Richard Weinberger]

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