Re: context switch vs. signal delivery [was: Re: Accelerating user mode

From: Udo A. Steinberg (
Date: Tue Aug 06 2002 - 11:02:02 EST

On Tue, 06 Aug 2002 10:12:25 -0400
Jeff Dike <> wrote:

> Indeed. I misread the !capable(CAP_KILL) as "I am not allowed to kill the
> other guy", which clearly you are when you just forked it.
> This looks like a bug to me. If you own the process, you can send it any
> signal you want, so you should be allowed to sign it up for SIGURG/SIGIO via

I'm glad we agree on that one :)

Considering we're not using sockets with broken SIGIO, but pseudo-terminals
like UML instead, there's still a problem:

When the task is registered as socket owner and is just about to enter the
kernel due to a syscall, it will stop with a SIGTRAP and the tracing kernel
process will run sometime and see a SIGCHLD. But after the task stopped and
before the kernel process can change SIGIO ownership back, a new interrupt
could come in and the SIGIO would remain pending in the task's process until
the task was scheduled to run next time.

How do you solve this?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:31 EST