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

Udo A. Steinberg
2002-08-06T15:59:04Z

On Tue, 06 Aug 2002 10:12:25 -0400
Jeff Dike <jdike@karaya.com> 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
> F_SETOWN.

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?

-Udo.