All of lore.kernel.org
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paolo Ornati <ornati@fastwebnet.it>,
	linux-kernel@vger.kernel.org, akpm@osdl.org, torvalds@osdl.org
Subject: Re: [PATCH] select: fix sys_select to not leak ERESTARTNOHAND to userspace
Date: Mon, 22 Jan 2007 11:24:06 -0500	[thread overview]
Message-ID: <20070122162406.GC21059@hmsreliant.homelinux.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0701220758120.32200@woody.linux-foundation.org>

On Mon, Jan 22, 2007 at 08:03:53AM -0800, Linus Torvalds wrote:
> 
> 
> On Mon, 22 Jan 2007, Neil Horman wrote:
> 
> > On Mon, Jan 22, 2007 at 02:59:56PM +0100, Paolo Ornati wrote:
> > > 
> > > the ERESTARTNOHAND thing is handled in arch specific signal code,
> > 
> > In the signal handling path yes.
> 
> Right.
> 
> > Not always in the case of select, though.  Check core_sys_select:
> 
> No, even in the case of select().
> 
> > if (!ret) {
> >                 ret = -ERESTARTNOHAND;
> >                 if (signal_pending(current))
> >                         goto out;
> >                 ret = 0;
> 
> Since we have "signal_pending(current)" being true, we _know_ that the 
> signal handling path will be triggered, so the ERESTARTNOHAND will be 
> changed into the appropriate error return (or restart) by the signal 
> handling code.
> 
> > Its possible for core_sys_select to return ERESTARTNOHAND to sys_select, which
> > will in turn (as its currently written), return that value back to user space.
> 
> No. Exactly because sys_select() will always return through the system 
> call handling path, and that will turn the ERESTARTNOHAND into something 
> else.
> 
> NOTE! If you use "ptrace()", you may see the internal errors. But that's a 
> ptrace-only thing, and may have fooled you into thinking that the actual 
> _application_ sees those internal errors. It won't.
> 
> Of course, we could have some signal-handling bug here, but if so, it 
> would affect a lot more than just select(). Have you actually seen 
> ERESTARTNOINTR in the app (not just ptrace?)
> 
The error was reported to me second hand.  I'm expecting a reproducer (although
to date, I'm still waiting for it, so I may have jumped the gun here).  In fact,
I see what your saying now, down in the assembly glue for our arches (x86 in
this case) we jump to do_notify_resume since we have a pending signal, and
inside do_signal from there we fix up ERESTARTNOHAND to be something sane for
userspace.  Ok, I withdraw this patch.  I'll repost when/if I get my hands on
the reproducer and see that something is actually slipping through.

Neil

> 		Linus

  reply	other threads:[~2007-01-22 16:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-16 20:13 [PATCH] select: fix sys_select to not leak ERESTARTNOHAND to userspace Neil Horman
2007-01-22 13:59 ` Paolo Ornati
2007-01-22 14:52   ` Neil Horman
2007-01-22 16:03     ` Linus Torvalds
2007-01-22 16:24       ` Neil Horman [this message]
2007-01-23  0:00         ` bert hubert
2007-01-24  5:59 ` David Miller
2007-01-24 13:21   ` Neil Horman
2007-01-22 13:00 Neil Horman
2007-01-22 23:02 ` Andi Kleen
2007-01-23 18:55   ` Neil Horman
2007-08-17 15:41 John Blackwood
2007-08-17 20:55 ` Neil Horman

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=20070122162406.GC21059@hmsreliant.homelinux.net \
    --to=nhorman@tuxdriver.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ornati@fastwebnet.it \
    --cc=torvalds@linux-foundation.org \
    --cc=torvalds@osdl.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.