[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201205010106.38495.vapier@gentoo.org>
Date: Tue, 1 May 2012 01:06:36 -0400
From: Mike Frysinger <vapier@...too.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Chen Liqin <liqin.chen@...plusct.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
Oleg Nesterov <oleg@...hat.com>
Subject: Re: [RFC] TIF_NOTIFY_RESUME, arch/*/*/*signal*.c and all such
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
Download attachment "signature.asc " of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists