Messages in this thread | | | Date | Sun, 15 Oct 2006 20:37:40 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [PATCH] generic signal code (small new feature - userspace signal mask), kernel 2.6.16 |
| |
On Sun, 15 Oct 2006, Gareth Knight wrote: > > I looked in MAINTAINERS for a suitable person for the generic signal code, but > couldn't find anyone in particular. Please Cc me on comments, which are most > welcome, as I am not on LKML, although I do peruse the archives.
That's a truly horribly disfigured patch - your whitespace is all screwed up.
Anyway, the whole approach is not doable. At all.
Why? You're doing user-space accesses from within critical sections with a spinlock, and that's just a big no-no. Think page faults, swapping etc.
That's ignoring all the issues with the fact that doing the user accesses during recalc_sigpending is broken for other reasons, namely that we don't even _do_ the signal pending recalculation all the time, just when we "know" things may have changed. So your approach would miss updates to the user-space masks.
So the whole approach is flawed.
You _could_ try to make it do something special at signal delivery time, to see if delivery can be delayed at that point, but quite frankly, it's going to be nasty there too (and that's going to be a disaster for the whole issue of non-thread-specific signals, which have been steered to one thread, and then the new mask would say that they can't be accepted by that thread after all).
Quite frankly, you'd probably be better off trying to do totally different approaches. For example, it would be possible to block all signals entirely, and then just create a new system call that uses a _synchronous_ delivery method to avoid races with async delivery. Preferably a file descriptor, so that you can select/poll on it.
That was discussed at some point. See for example:
http://groups.google.com/group/linux.kernel/browse_thread/thread/1332715ae3e26b9/1f3fc521db812a07?lnk=st&q=&rnum=1&hl=en#1f3fc521db812a07
which I found by just googling for "synchronous signal queue" with me as the author. That's from almost four years ago, and nobody ever got quite excited enough about it to actually take it any further, but I still think it's a lot better than the alternatives like yours..
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |