linux-kernel - Re: [RESEND] [RFC][PATCH X86_32 1/2]: Call do_notify

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 26 Oct 2011 10:34:38 -0700 (PDT)
From:	Roland McGrath <roland@...k.frob.com>
To:	Russell King <rmk@....linux.org.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Christoph Hellwig <hch@...radead.org>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andi Kleen <andi@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Shuah Khan <shuah.khan@...com>, Ingo Molnar <mingo@...e.hu>,
	Alexander van Heukelum <heukelum@...tmail.fm>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND] [RFC][PATCH X86_32 1/2]: Call do_notify_resume() with
	interrupts enabled

> 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

I don't think this is a violation.  That ERESTARTNOHAND referred to
restarting for the signal that interrupted that first syscall.  That
decision has already been made.  You can consider that restart already to
have begun before the second signal arrives.  In essence, it's like the
first syscall had never been entered, because the user state is already
rolled back to where the syscall instruction is about to execute (correct
me if I'm wrong about that).  Then the second signal comes along and
prevents that instruction from executing.  It's really no different from if
you had gotten all the way back to user mode, but not yet executed the
first user instruction (i.e. the syscall instruction), when the second
signal interrupted the user task.

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

I'm personally for caring about all cases, no matter how obscure.  For that
particular one, I don't think I see the problem.  I'm probably overlooking
something.  ERESTARTSYS says that the user state should be rolled back to
the syscall instruction before the handler setup.  So it's just as if the
signal had arrived before user mode executed the syscall instruction in the
first place.  That just affects the sigcontext saved before the handler
runs.  Nothing about that interacts with further interruptions during the
handler.  What am I missing?

However, we already have the fundamental constraint that
ERESTART_RESTARTBLOCK states are lost when a handler runs.

Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/