Messages in this thread | | | From | Roland McGrath <> | Subject | Re: [RESEND] [RFC][PATCH X86_32 1/2]: Call do_notify_resume() with interrupts enabled | Date | Wed, 26 Oct 2011 10:34:38 -0700 (PDT) |
| |
> 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
| |