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

["Kilau, Scott" <Scott_Kilau@digi.com>]

> Okay. I have to take a "work break", but you can check the
> driver and see if the code is interruptible (it must be)
> and if there is something like if(signal_pending(current))
> get_to_hell_out_of_this_loop.... in the time-out loop.

Hi Dick,
I don't believe this is a serial driver problem.

In /usr/src/linux-2.6.13/drivers/serial/serial_core.c ->
uart_wait_until_sent()

You can see that it does this:

while (!port->ops->tx_empty(port)) {
	msleep_interruptible(jiffies_to_msecs(char_time));
	if (signal_pending(current))
		break;
	if (time_after(jiffies, expire))
		break;
	}

Since we know that tx will never be empty because of flow control,
the only way this guy is going to bail, is if it times out,
or if it signal_pending() comes back with something.

signal_pending() never does, no matter how many signals I send it.
(Even sending it multiple kill -9's)

Eventually it times out (after 30 seconds, "setserial closing_wait"),
and then the process goes away.

However, I see the signals climb, when I print out the values of
current->signal->shared_pending.list.next and
current->signal->shared_pending.list.prev

Its like those values and the signal_pending macro aren't in "synch"
Anymore, once the process has gone into the PF_EXITING state.
(It works fine when the process is not in that state)

Thanks!
Scott
-
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/