Re: [PATCH] PPC32: cancel syscall restart on signal delivery

[Linus Torvalds]

On Sat, 15 Nov 2003, Paul Mackerras wrote:
> 
> (Having interrupts disabled during do_signal is interesting, given
> that its subroutines call __put_user and friends. :)

Actually, look closer. We don't do that.

Why? Check out get_signal_to_deliver(). And grok the absolute horridness.

> Thus I think the race was possibly a little wider on PPC than on x86:
> we didn't have to get back to userspace, the interrupt could happen
> during do_signal.

No. If it happens during do_signal() (on x86 or ppc), we'd just not
_handle_ the signal at all. We'd return to user space, restart the system 
call, and handle the signal as the restarted system call is returning. No 
bug.

In short, even on ppc, the window _literally_ is "after we've returned, 
but before we restart". 

> Now you have me scared, because I can't see where the restart_syscall
> system call resets current_thread_info()->restart_block.fn to
> do_no_restart_syscall.

It doesn't. 

The rule is: the restart_block is _only_ meaningful if you return 
-ERESTART_BLOCK. So at any other time it contains stale data.

> Am I missing something?  Perhaps we should reset restart_block.fn in
> sys_{,rt_}sigreturn, or possibly in sys_restart_syscall.

You're missing that the only thing that ever looks at restart_block is the 
code that is inside the signal handling of ERESTART_BLOCK.

The bug was that sometimes we had _already_ done that ERESTART_BLOCK 
handling (correctly), but then basically "aborted" (thanks to another 
signal) before the restart had actually taken effect.

And that race literally is only in user mode.

		Linus

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