[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: manipulating sigmask from filesystems and drivers
From:       Linus Torvalds <torvalds () transmeta ! com>
Date:       2002-08-01 19:09:04
[Download RAW message or body]


On Wed, 31 Jul 2002, David Howells wrote:
> 
> Can you comment on whether a driver is allowed to block signals like this, and
> whether they should be waiting in TASK_UNINTERRUPTIBLE?

They should be waiting in TASK_UNINTERRUPTIBLE, and we should add a flag 
to distinguish between "increases load average" and "doesn't". So you 
could have

	TASK_WAKESIGNAL - wake on all signals
	TASK_WAKEKILL	- wake on signals that are deadly
	TASK_NOSIGNAL	- don't wake on signals
	TASK_LOADAVG	- counts toward loadaverage

	#define TASK_UNINTERRUPTIBLE	(TASK_NOSIGNAL | TASK_LOADAVG)
	#define TASK_INTERRUPTIBLE	TASK_WAKESIGNAL

and then people who wanted to could use other combinations. The
TASK_WAKEKILL thing is useful - there are many loops that cannot exit
until they have a result, simply because the calling conventions require 
that. Th emost common example is disk wait.

HOWEVER, if they are killed by a signal, the calling convention doesn't
matter, and the read() or whatever could just return 0 (knowing that the
process will never see it), and leave a locked page locked. Things like 
generic_file_read() could easily use this, and make processes killable 
even when they are waiting for a hung NFS mount - regardless of any soft 
mount issues, and without NFS having to have special code.

In the end, I'm too lazy, and I don't care. So I can only tell you how it 
_should_ be done, and maybe you can tell somebody else until the sucker to 
actually do it is found.

		Linus

-
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/
[prev in list] [next in list] [prev in thread] [next in thread]