Re: [RESEND] [RFC][PATCH X86_32 1/2]: Call do_notify_resume() withinterrupts enabled

[Roland McGrath]

> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/