From: Al Viro <viro@ZenIV.linux.org.uk>
To: Richard Weinberger <richard@nod.at>
Cc: stable@vger.kernel.org, linux-kernel@vger.kernel.org,
user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] [PATCH] um: Fix get_signal() usage
Date: Sat, 9 Jan 2016 04:09:25 +0000 [thread overview]
Message-ID: <20160109040925.GC17997@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20160109035125.GA365@ZenIV.linux.org.uk>
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
next prev parent reply other threads:[~2016-01-09 4:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-18 8:51 [PATCH] um: Fix get_signal() usage Richard Weinberger
2016-01-09 3:51 ` Al Viro
2016-01-09 4:09 ` Al Viro [this message]
2016-01-09 9:52 ` Richard Weinberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160109040925.GC17997@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=richard@nod.at \
--cc=stable@vger.kernel.org \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).