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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
