Re: signal handling (clarification needed)

From: Talib Alim
Date: Mon May 22 2006 - 02:05:46 EST

hello talib..

> if (signal_pending)
> {
> return -EINTER
> }

I think this is the problem. You return -EINTR no matter what signal is currently pending. try to study next_signal() in kernel/signal.c, I think by using this function, you can get the signal number of the
pending signal(s), thus you can act accordingly.

I understand this is the problem, but I do not want to get in the business of handling signals in my driver. If I dequeue the signal, than It has to be resent (by my driver) when process is goes to user space, what if that signal has signal handler ? than I have to run that too.

As I mentioned earlier, accept also does same thing, i.e. it returns on signal_pending true.

My point is what is the correct way of taking care of this situation, i.e. driver operating on behave of user process (in kernel context), how should suspend signal handled ? if I do not check for signal_pending, than ctrl-c will not work, and if e.g. read (or accept) does not get any data (connection) than this program will be struck in kernel mode.

I think I am missing some some point, I hope that somebody can help me understand this.

Talib Alim

Since I am not sure if this function is exported, maybe you can use dequeue_signal() instead (also defined in kernel/signal.c).

Good luck...



Don?t just search. Find. Check out the new MSN Search!

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at