From mboxrd@z Thu Jan  1 00:00:00 1970
From: Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: lockd's interactions with locks.c
Date: 02 Aug 2002 17:56:49 +0200
Sender: linux-fsdevel-owner@vger.kernel.org
Message-ID: <shsfzxxckzi.fsf@charged.uio.no>
References: <20020801022821.E3797@parcelfarce.linux.theplanet.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-fsdevel@vger.kernel.org, neilb@cse.unsw.edu.au,
	nfs-devel@linux.kernel.org, trond.myklebust@fys.uio.no,
	okir@monad.swb.de
Return-path: <linux-fsdevel-owner@vger.kernel.org>
To: Matthew Wilcox <willy@debian.org>
In-Reply-To: <20020801022821.E3797@parcelfarce.linux.theplanet.co.uk>
List-Id: linux-fsdevel.vger.kernel.org

>>>>> " " == Matthew Wilcox <willy@debian.org> writes:

     > There's no-one specifically listed as maintaining lockd, so i'm
     > cc'ing everyone involved with NFS.

<snip>

     > Now, unless we export a lock from locks.c that lockd can grab
     > around all this, we're pretty much hosed.  I believe that lockd
     > runs with the BKL at this point, so there's no race currently.
     > Here's my preferred alternative (untested, i want to get
     > comments on the idea):

I'm not sure I understand how are you are planning on protecting
against races with the blocking code? For instance

     lockd:                                 Another process:

                                            posix_lock_file();
   posix_lock_file();

                                           releases file lock;

  grab_lockd_blocking_lock();
  nlmsvc_insert_block();
  have_been_woken_up_already = ...;
  release_lockd_blocking_lock();


Is this a situation where the mysterious 'have_been_woken_up_already'
kicks in in order to tell lockd not to block after all? If so, how do
you see that part being implemented?

Cheers,
  Trond