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

[Paul Mackerras]

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