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

[Mike Frysinger]

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

Attachment: signature.asc
Description: This is a digitally signed message part.