Messages in this thread | | | Date | Sat, 15 Nov 2003 16:03:57 +1100 | From | Paul Mackerras <> | Subject | Re: [PATCH] PPC32: cancel syscall restart on signal delivery |
| |
Linus Torvalds writes:
> Why? Check out get_signal_to_deliver(). And grok the absolute horridness.
Yes, that is pretty special, isn't it. :)
> 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.
... and sys_restart_syscall(). If your statement was true, why was it so important to reset restart_block.fn when we deliver a signal?
Seems to me that we can get into a situation where we are in a signal handler, and the interrupted state has (1) eip/nip pointing at a system call instruction and (2) the syscall number register (eax/r0) containing __NR_restart_syscall. Now, if we get into this state we will initially have restart_block.fn == do_no_restart_syscall. But that can get changed by the signal handler.
Now, when we resume that context we will call sys_restart_syscall which will call restart_block.fn. Which won't necessarily still point to do_no_restart_syscall. So I still think we have a problem.
Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |