Re: [RFC] TIF_NOTIFY_RESUME, arch/*/*/*signal*.c and all such

[Al Viro]

On Wed, Apr 25, 2012 at 07:02:30PM +0200, Oleg Nesterov wrote:

> And there is another case:
> 
> 	syscall interrupted, it returns ERESTARTSYS.
> 
> 	do_signal() sees no signal, restarts the syscall
> 
> 	!SA_RESTART comes before we return to user-mode
> 
> This doesn't really differ from sigsuspend/ERESTARTNOHAND we discussed
> before.

... and dealt with the same way:
	NEED_RESTART flag is set the first time around
	no handler for the first signal, so we do nothing else
	handler is found for the second signal
	NEED_RESTART flag is present, so
		we clear NEED_RESTART
		we look at errno and see ERESTARTSYS
		we check sa_flags and see !SA_RESTART
		we set return value to -EINTR and proceed to set sigframe up
	on the exit to userland we see NEED_RESTART not set, so off we go
I think I hadn't been clear enough; here's pseudocode for what I meant

do_signal()
{
	if (we have any business doing restarts)
		// note: we won't get here on subsequent calls of do_signal()
		// due to the checks above; same logics that currently prevents
		// double restarts
		set NEED_RESTART flag
	sig = get_signal_to_deliver(...)
	if (sig) {
		if (NEED_RESTART set) {
			clear NEED_RESTART
			same thing we do at that spot now - restart or EINTR
			handle_signal(...)
			...
			return;
		}
	}
	/* no handler */
	if (test_and_clear_...(RESTORE_SIGMASK))
		set_current_blocked(&current->saved_sigmask);
}
and in asm glue, *after* checking for SIGPENDING/NOTIFY_RESUME, check
NEED_RESTART and if it's set do what we currently do for restarts on
handlerless signal.

BTW, if we combine that with ERESTART_RESTARTBLOCK trick on arm/parisc/unicore,
there won't be much work to do for restarts in that case; in x86ese it
would be simply
	if (regs->ax == -ERESTART_RESTARTBLOCK)
		set_thread_flag(TIF_EMULATE_RESTART_SYSCALL)
	regs->ax = regs->orig_ax;
	regs->ip -= 2;
all of that conditional on TS_NEED_RESTART...
--
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/