All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaud Giersch <arnaud.giersch-T9cNH8bv7N6Vy8wrSkPSsihWMY4UYrEW@public.gmane.org>
To: linux-nfs@vger.kernel.org
Subject: Re: BUG: cannot acquire lock twice with NFSv4
Date: Sat, 10 Apr 2010 10:46:58 +0200	[thread overview]
Message-ID: <wwed3y73da5.fsf@powwow.iut-bm.univ-fcomte.fr> (raw)
In-Reply-To: <wwer5mo3hf9.fsf-RvotKtm/pmVc2QSU14wbDhqUABtTHcxU/fObgANad5s@public.gmane.org> (Arnaud Giersch's message of "Fri, 09 Apr 2010 15:05:14 +0200")

Vendredi 09 avril 2010, vers 15:05:14 (+0200), j'ai =C3=A9crit=C2=A0:

>   1. opens a first file, and acquires read lock on it ;
>   2. opens a second file, and acquires read lock on it ;
>   3. releases locks, and closes files.
>
> Both opened files are of course on the NFS mount.  On the first run, =
all
> seems to be fine.  On the second (and subsequent) runs, the lock is
> refused at step 2 with errno=3D37 (ENOLCK, No locks available).

I noticed that things appear to work as expected if commit
8e469ebd6dc32cbaf620e134d79f740bf0ebab79 (NFSv4: Don't allow posix
locking against servers that don't support it) is reverted.

=46rom what I can see, the client is granted a read delegation for the
second file.  On the second run, the client fetches some cached state
for this file.

On this second run, state->flags (as in _nfs4_do_open, or in
nfs4_proc_lock) only contains NFS_DELEGATED_STATE, while on the first
run, it also contained NFS_O_RDONLY_STATE and NFS_STATE_POSIX_LOCKS.

Then, I do not fully understand the code, and I am not able to suggest
any satisfying patch to correct the problem.

Regards,

        Arnaud Giersch

  parent reply	other threads:[~2010-04-10  8:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-09 13:05 BUG: cannot acquire lock twice with NFSv4 Arnaud Giersch
     [not found] ` <wwer5mo3hf9.fsf-RvotKtm/pmVc2QSU14wbDhqUABtTHcxU/fObgANad5s@public.gmane.org>
2010-04-10  8:46   ` Arnaud Giersch [this message]
     [not found]     ` <wwed3y73da5.fsf-RvotKtm/pmVc2QSU14wbDhqUABtTHcxU/fObgANad5s@public.gmane.org>
2010-04-11 15:24       ` Trond Myklebust
2010-04-11 20:50         ` Trond Myklebust
2010-04-12 10:32           ` Arnaud Giersch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=wwed3y73da5.fsf@powwow.iut-bm.univ-fcomte.fr \
    --to=arnaud.giersch-t9cnh8bv7n6vy8wrskpssihwmy4uyrew@public.gmane.org \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.