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(¤t->sigmask_lock);
saved_set = current->blocked;
sigfillset(¤t->blocked);
recalc_sigpending(current);
spin_unlock_irq(¤t->sigmask_lock);
schedule();
remove_wait_queue(cv, &wait);
spin_lock_irq(¤t->sigmask_lock);
current->blocked = saved_set;
recalc_sigpending(current);
spin_unlock_irq(¤t->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/