Thread (23 messages) 23 messages, 6 authors, 2012-05-02

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

From: Mike Frysinger <hidden>
Date: 2012-05-01 05:06:08
Also in: lkml

Possibly related (same subject, not in this thread)

On Tuesday 01 May 2012 00:31:29 Al Viro wrote:
blackfin: no loop (== multiple signals handling is fucked); no check either
        ret_from_fork doesn't handle signals, etc., userland or not.
        kernel_execve doesn't handle signals, etc., success or no success
        conclusion: check is probably not needed, multiple pending signals
are screwed
to be honest, i haven't been following this thread as Blackfin wasn't mentioned 
in the initial summary.  now it seems we have ;).  i tried going back through 
this TIF_NOTIFY_RESUME thread but haven't quite got a bead on what needs to be 
done.

seems like you're only referring to ret_from_fork here and not the normal 
syscall return path ?  in the Blackfin case, we don't have a fork(), so we only 
have to handle the supervisor mode case (spawning kthreads), so i don't think 
we're quite as fucked as you might think :).

what is it you're suggesting we add ?  in the past, i found documentation on 
the arch TIF_*/notify requirements to be pretty much non-existent.  so some 
parts of the Blackfin paths are what i found from my eyes bleeding x86 asm 
paths, and from single testing some random tests (like strace or gdb).  things 
seem to run & be debugable, and no one has complained thus far, so we ship it!
-mike

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help