To: torvalds@transmeta.com, alan@redhat.com
Cc: linux-kernel@vger.kernel.org, dhowells@redhat.com
Subject: manipulating sigmask from filesystems and drivers
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 31 Jul 2002 12:52:43 +0100
Message-ID: <15189.1028116363@warthog.cambridge.redhat.com>
From: David Howells <dhowells@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2055
Lines: 65


Hi Linus, Alan,

Can you confirm that this is A Bad Thing(TM)? I've been poking around in the
OpenAFS filesystem driver, and it tries to achieve uninterruptible I/O waiting
by the following means:

	/* CV_WAIT and CV_TIMEDWAIT rely on the fact that the Linux kernel has
	 * a global lock. Thus we can safely drop our locks before calling the
	 * kernel sleep services.
	 */
	static inline int CV_WAIT(afs_kcondvar_t *cv, afs_kmutex_t *l)
	{
	    int isAFSGlocked = ISAFS_GLOCK(); 
	    sigset_t saved_set;
	#ifdef DECLARE_WAITQUEUE
	    DECLARE_WAITQUEUE(wait, current);
	#else
	    struct wait_queue wait = { current, NULL };
	#endif

	    add_wait_queue((wait_queue_head_t *)cv, &wait);
	    set_current_state(TASK_INTERRUPTIBLE);

	    if (isAFSGlocked) AFS_GUNLOCK();
	    MUTEX_EXIT(l);

	    spin_lock_irq(&current->sigmask_lock);
	    saved_set = current->blocked;
	    sigfillset(&current->blocked);
	    recalc_sigpending(current);
	    spin_unlock_irq(&current->sigmask_lock);

	    schedule();
	    remove_wait_queue(cv, &wait);

	    spin_lock_irq(&current->sigmask_lock);
	    current->blocked = saved_set;
	    recalc_sigpending(current);
	    spin_unlock_irq(&current->sigmask_lock);

	    if (isAFSGlocked) AFS_GLOCK();
	    MUTEX_ENTER(l);

	    return 0;
	}

The reason for them doing this is so that they can get the process to appear
in the "S" state and thus avoid increasing the load average.

What I'm concerned about is that they wait for an event to happen by blocking
all signals (by accessing the process's signal masks directly) and then
sitting in TASK_INTERRUPTIBLE (which _mostly_ works, but ptrace(PTRACE_KILL)
can interrupt).

Can you comment on whether a driver is allowed to block signals like this, and
whether they should be waiting in TASK_UNINTERRUPTIBLE?

Cheers,
David
-
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/