lkml.org 
[lkml]   [2012]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] TIF_NOTIFY_RESUME, arch/*/*/*signal*.c and all such
On 04/26, Martin Schwidefsky wrote:
>
> On Wed, 25 Apr 2012 18:51:13 +0100
> Al Viro <viro@ZenIV.linux.org.uk> wrote:
>
> > 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.
>
> You need to be careful with inferior calls there. gdb likes to play games
> with the registers inside the get_signal_to_deliver call, it wants to be
> able to jump out of an interrupted system call, do its inferior call in
> the debugee and then return to the interrupted system call.

Ah.

> You would have to to read, modify & restore the NEED_RESTART flag in gdb
> over an inferior call.

I am not sure, but perhaps this is not really needed...

But at least this means that "if (we have any business doing restarts)"
above is meaningless before get_signal_to_deliver().


And I am confused, off-topic question... How it is possible to
"then return to the interrupted system call" if that system call
returned -ERESTART_RESTARTBLOCK but the inferior call in turn
does the system call which changes restart_block->fn/etc ?

Oleg.



\
 
 \ /
  Last update: 2012-04-26 15:57    [W:0.130 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site