A way to cancel delivery / push things back onto the signal queue
would indeed be a worthy addition. The way I would see that working
would be where you passed a special or new parameter to sigreturn()
to indicate you wanted that signal requeued, presumably the
implication would be that is was also added to the blocked mask at
the same time.
The scheme for critical sections described below is a decent
compromise, but it does require more application change than just
speeding up sigprocmask. My idea was that glibc could take advantage
of the sigprocmask speedup when it was available and thus you
automatically roll out the benefit to existing applications.
Linus pretty much mauled the suggested patch, but I don't think its
quite as bad as it may first appear. The suggestion from Andi to
pin / lock the page (inspired from the futex code) I think solves a
number of edge cases right off the bat and is straightforward to do.
The concern over a copy_from_user whilst holding the ¤t-
>sighand->siglock I think is just a case of ensuring
recalc_sigpending is not called in that situation - it doesn't seem
necessary to hold the siglock to recalc the pending signals.
I also re-read the signal code and whilst it is quite true that
recalc_sigpending is not called in every path, the omissions seem to
me to be places that would be irrelevant anyway - in the case of
forcing signal delivery for instance, where you wish to ignore any mask.
I do agree that in the case of unblocking a pending signal with my
scheme, delivery is not instantaneous (typically the next syscall),
but I would argue that this is only the case for signals which would
not have been temporally deterministic anyway - some synchronous
event such as a SIGBUS will cause pre-emption in a deterministic
manner as always.
Suggestions and comments most welcome,
Gareth.
This is a proposed addition to the linux kernel to reduce the
overhead required to mask signals. The intended usage is an
application with critical sections that need to be guarded against
deadlock by preventing signals from being delivered whilst inside one
of the critical sections. Currently such applications may be very
heavy users of the sigprocmask syscall, this proposal provides an
additional signal mask stored in userspace that can be updated with a
simple store rather than a syscall.
Wouldn't a simpler solution be to provide a way to cancel signal
delivery after it's hit user-space?
Then user space can keep its own block mask, which is maintained as
a superset of the kernel block mask. Then a critical section would,
in the fast path, proceed like:
- Block signals -> Noted in user-space only
- Do critical section (part 1)
- Do critical section (part 2)
- Unblock signals -> Noted in user-space only
- More code
And if something bad happened
- Block signals -> Noted in user-space only
- Do critical section (part 1)
- Signal arrives
- Test against user-space mask
- Tell kernel about all blocked signals -> Note new kernel mask
- Return "please try again later" from signal handler
- Do critical section (part 2)
- Unblock signals -> Note that it's less than kernel mask
- Tell kernel about newly unblocked signals
- Signal arrives (again)
- Test against user-space mask
- Call registered signal handler
- Return "signal handled"
- More code
This does do the whole signal delivery dance twice if it gets unlucky,
but keeps a conceptually simpler kernel interface.
The one thing that might be complicated is pthread signal delivery.
"Please try again later" could need to go back to the process layer
and
immediately re-deliver it to a different thread.
-
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]
