Yup, sorry. That test is wrong, and is slated to be fixed at some point.
> 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?
A couple of ways. The system call path can call sigio_handler to clear
out any pending IO. The SIGIO that was trapped in the process will cause
another call to sigio_handler which won't turn up any IO, but I don't
consider that to be a problem.
The kernel process can examine the signal pending mask of the process after
it has transferred SIGIO to itself. This can be done either through
/proc/<pid>/status or a ptrace extension, since we're happily postulating
new things for it to do anyway. If there is a SIGIO pending, it calls
sigio_handler.
Any other possibilities that you see?
Jeff
-
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/