On Sat, Feb 03, 2007 at 04:40:05PM -0800, Trond Myklebust wrote: > On Sat, 2007-02-03 at 00:34 -0500, J. Bruce Fields wrote: > > nlmsvc_notify_blocked(struct file_lock *fl, struct file_lock *conf, int result) > > { > > struct nlm_block *block; > > + int rc = -ENOENT; > > > > dprintk("lockd: nlmsvc_notify_blocked lock %p conf %p result %d\n", > > fl, conf, result); > > + lock_kernel(); > > list_for_each_entry(block, &nlm_blocked, b_list) { > > if (nlm_compare_locks(&block->b_call->a_args.lock.fl, fl)) { > > + dprintk("lockd: nlmsvc_notify_blocked block %p flags %d\n", > > + block, block->b_flags); > > + if (block->b_flags & B_QUEUED) { > > + if (block->b_flags & B_TOO_LATE) { > > + rc = -ENOLCK; > > + break; > > + } > > + nlmsvc_update_deferred_block(block, conf, result); > > but nlmsvc_update_deferred_block() can sleep! Yep, you're right. Fortunately, the only reason it sleeps is a single allocation that's probably easy enough to do elsewhere, which I believe would fix this: > How are you protecting against races with notification? Also, how are > you guaranteeing that the block queue won't change underneath you when > you lose the BKL. --b. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html