[BUG?] 2.6.x (2.6.13) - new signals not being delivered to a terminating (PF_EXITING) process.

[Kilau, Scott]

Hi everyone,

This email will deal with the serial/tty layer of the kernel,
but I don't think its completely isolated to this layer...

I have found a problem with signals not getting delivered to a
Process once it enters into the PF_EXITING state.

Probably the best way to show it, is an example with the built-in
COM port.

1) Don't have anything connected to COM1.
2) stty -ixon -ixoff -ixany crtscts < /dev/ttyS0
3) date > /dev/ttyS0
4) Press ctrl-c.

The process does get this ctrl-c, and starts closing down.

The serial driver gets its "tty close" for ttyS0, as it should,
and goes into a "drain" waiting for the data that is pending
in the UART to be written.

(Which can never be written, because the port is stuck in a
hardware flow control state)

5) Press ctrl-c again... And again, and again, and again.  Nothing.

The process is stuck, and a ps -ef shows that it is in a
zombie state ([date])

Under stock 2.4 kernels, the 2nd and subsequent ctrl-c's would wake
up the serial driver's "wait" with a signal, which in turn would
allow the serial driver to bail out of the forever "drain",
and complete the close.

Now, eventually, the "date" will bail, but only because the serial
driver has a "timeout" set for the wait in its drain routine.
It still never receives the 2nd+ ctrl-c's.

Is this change intentional?
If so, why?

Thanks!
Scott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/