Messages in this thread | | | From | Gareth Knight <> | Date | Sun, 15 Oct 2006 20:50:37 -0700 | Subject | Re: [PATCH] generic signal code (small new feature - userspace signal mask), kernel 2.6.16 |
| |
Hey Linus,
Thanks for the lightning fast response !
I take your points - the reason I favoured trying userspace access approach was to keep the feature portable. I've seen this feature in other *nix kernels but always done with the mask kept on some sort of syspage shared between user and kernel space, at a fixed address but contents local to each thread. I would love to add such a feature to Linux - perhaps keep the tid, timeofday and other popular things on there as well; however I felt that sort of work was beyond my kernel hacking abilities right now. I guess it could either be done as an outright special case or part of supporting a MAP_LOCAL style of mmap on Linux.
I did google for MAP_LOCAL and syspage, but I didn't see any promising avenues in terms of previous work I could pickup.
Gareth.
> > > 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/
| |