lkml.org 
[lkml]   [2003]   [Nov]   [15]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSat, 15 Nov 2003 16:03:57 +1100
FromPaul Mackerras <>
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 12:58    [from the cache]
©2003-2008