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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
