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

[Linus Torvalds]

On Sat, 15 Nov 2003, Paul Mackerras wrote:
> 
> BTW, do we have a test program that triggers the bug that this fixes?

No. In fact, it's an _incredibly_ tiny race, because the old code that 
only handled it at the return path of the system call that got interrupted 
would catch the thing in all cases _except_ if the system

 (a) decided to restart the system call
 (b) got an interrupt _after_ the return to user mode but _before_ the 
     system call instruction itself actually did the restart
 (c) this interrupt caused a new signal with a handler (different from the
     one that caused the restart, since that one by definition had no
     handler) to the same program.

On x86, for the old calling conventions (ie "int 0x80"), that meant that 
the interrupt window was literally a single instruction. For the new one 
("sysenter") it was two instructions.  So you literally need a minimum of 
two different signals, and a incredibly tight window.

To make it even worse, even if the above incredibly unlikely thing
actually _happens_, most of the time it wouldn't really matter. The worst
case schenario is that the signal handler itself does a system call that
needs restarting, in which case on signal handler return we now restart
the _wrong_ system call once we return. But a more likely schenario is
that we restart the right system call after the signal handler has run,
rather than returning EINTR.

Quite frankly, the only reason I even thought about it was due to the 
clock_nanosleep() patch to fix the posix timer restart code. Which just 
made me trace the sequence again in my head.

			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/