lkml.org 
[lkml]   [2005]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: [BUG?] 2.6.x (2.6.13) - new signals not being delivered to a terminating (PF_EXITING) process.
Date
From

> 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/

\
 
 \ /
  Last update: 2005-10-11 22:33    [W:0.018 / U:2.004 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site