Re: [PATCH] generic signal code (small new feature - userspace signal mask), kernel 2.6.16

[Gareth Knight <gk@garethknight.com>]

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/