All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>,
	Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Christoph Hellwig <hch@infradead.org>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andi Kleen <andi@firstfloor.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jim Keniston <jkenisto@linux.vnet.ibm.com>,
	Roland McGrath <roland@hack.frob.com>,
	Shuah Khan <shuah.khan@hp.com>, Ingo Molnar <mingo@elte.hu>,
	Alexander van Heukelum <heukelum@fastmail.fm>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RESEND] [RFC][PATCH X86_32 1/2]: Call do_notify_resume() with interrupts enabled
Date: Wed, 26 Oct 2011 16:10:05 +0100	[thread overview]
Message-ID: <20111026151005.GA1413@flint.arm.linux.org.uk> (raw)
In-Reply-To: <CA+55aFx4g-3yGOgdS-UOGGincbAOgdxwfHCHpd-yVU6-dKwv0w@mail.gmail.com>

On Wed, Oct 26, 2011 at 02:38:39PM +0200, Linus Torvalds wrote:
> Ingo, Thomas, I think this is your call, but it seems valid,

Hi Linus,

I guess I should've talked to you about this during a moment during the
kernel summit, but as I'm now back home it'll have to be email.

I've been toying with a similar patch for ARM, but I keep feeling uneasy
about having interrupts enabled in this path (even though they get enabled
in the depths of the signal handling code.)

I worry about are race condition like the following:

syscall enter
...
syscall returns -ERESTARTNOHAND
check for signal
	signal pending, but no handler, setup for restart
	interrupt happens, sets need_resched
need_resched set
	switch to another thread
...
	something happens which queues SIGIO
	switch back to this thread
check for signal
	signal pending, has handler, but we've setup for a restart
return to userspace
run SIGIO handler
restart syscall

This feels like it violates the expectations of the syscall being
restarted - which explicitly asks to be restarted only if there wasn't
a handler run.

I've been working on the assumption that this is a problem and we should
do something about it - but it's non-trivial to solve all the corner cases.
We can do a lot better with the restarting if we delay setting up for a
restart until either we setup the user stack for the sig handler or
immediately before returning to userspace (with a TIF flag.)

If you're interested in seeing where I got to, the patch is available at:
	https://lkml.org/lkml/2011/8/25/231

However, that doesn't solve the (probably unsolvable) case where an
ERESTARTSYS syscall is interrupted by a SA_RESTART-marked handler, and
while that handler is running it is then interrupted by a non-SA_RESTART-
marked handler.  I think that is far too an obscure case to care about
though.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

  reply	other threads:[~2011-10-26 15:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-25 14:18 [RESEND] [RFC][PATCH X86_32 1/2]: Call do_notify_resume() with interrupts enabled Srikar Dronamraju
2011-10-25 14:21 ` [RFC] [PATCH x86 2/2] Cleanup do_int3 Srikar Dronamraju
2011-10-25 15:52   ` Oleg Nesterov
2011-10-28  1:49   ` Masami Hiramatsu
2011-11-18  9:41     ` Srikar Dronamraju
2011-12-06  9:42   ` [tip:x86/asm] x86: Clean up and extend do_int3() tip-bot for Srikar Dronamraju
2011-10-25 16:14 ` [RESEND] [RFC][PATCH X86_32 1/2]: Call do_notify_resume() with interrupts enabled Oleg Nesterov
2011-10-26 12:38   ` Linus Torvalds
2011-10-26 15:10     ` Russell King [this message]
2011-10-26 17:34       ` Roland McGrath
2011-10-26 18:58       ` Oleg Nesterov
2011-11-03  4:43     ` Srikar Dronamraju
2011-12-06  9:42 ` [tip:x86/asm] x86: " tip-bot for Srikar Dronamraju

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=20111026151005.GA1413@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=ananth@in.ibm.com \
    --cc=andi@firstfloor.org \
    --cc=hch@infradead.org \
    --cc=heukelum@fastmail.fm \
    --cc=hpa@zytor.com \
    --cc=jkenisto@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=roland@hack.frob.com \
    --cc=rostedt@goodmis.org \
    --cc=shuah.khan@hp.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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.