lkml.org 
[lkml]   [2006]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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/

\
 
 \ /
  Last update: 2006-10-16 05:53    [W:0.060 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site