From: "J. Bruce Fields" <bfields@fieldses.org>
To: Jeff Layton <jlayton@redhat.com>
Cc: lkml@vger.kernel.org, linux-fsdevel@vger.kernel.org,
cluster-devel@redhat.com, linux-nfs@vger.kernel.org,
nfsv4@linux-nfs.org
Subject: Re: [PATCH 1/2] dlm: initialize file_lock struct in GETLK before copying conflicting lock
Date: Wed, 21 Jan 2009 18:42:39 -0500 [thread overview]
Message-ID: <20090121234239.GM4295@fieldses.org> (raw)
In-Reply-To: <1232555691-29859-2-git-send-email-jlayton@redhat.com>
On Wed, Jan 21, 2009 at 11:34:50AM -0500, Jeff Layton wrote:
> dlm_posix_get fills out the relevant fields in the file_lock before
> returning when there is a lock conflict, but doesn't clean out any of
> the other fields in the file_lock.
>
> When nfsd does a NFSv4 lockt call, it sets the fl_lmops to
> nfsd_posix_mng_ops before calling the lower fs. When the lock comes back
> after testing a lock on GFS2, it still has that field set. This confuses
> nfsd into thinking that the file_lock is a nfsd4 lock.
I think of the lock system as supporting two types of objects, both
stored in "struct lock"'s:
- Heavyweight locks: these have callbacks set and the filesystem
or lock manager could in theory have some private data
associated with them, so it's important that the appropriate
callbacks be called when they're released or copied. These
are what are actually passed to posix_lock_file() and kept on
the inode lock lists.
- Lightweight locks: just start, end, pid, flags, and type, with
everything zeroed out and/or ignored.
I don't see any reason why the lock passed into dlm_posix_get() needs to
be a heavyweight lock. In any case, if it were, then dlm_posix_get()
would need to release the passed-in-lock before initializing the new one
that it's returning.
The returned lock should probably also be a lightweight lock that's a
copy of whatever conflicting lock was found; otherwise we need to
require the caller to for example release the thing correctly.
That's unfortunate for nfsv4 since that doesn't allow returning the
lockowner information to the client. But it's not terribly important
to get that right.
Since gfs2 doesn't report the conflicting lock, I guess we just punt and
return a copy of the passed-in lock, OK.
--b.
>
> Fix this by making DLM reinitialize the file_lock before copying the
> fields from the conflicting lock.
>
> Signed-off-by: Jeff Layton <jlayton@redhat.com>
> ---
> fs/dlm/plock.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/fs/dlm/plock.c b/fs/dlm/plock.c
> index eba87ff..ca46f11 100644
> --- a/fs/dlm/plock.c
> +++ b/fs/dlm/plock.c
> @@ -304,7 +304,9 @@ int dlm_posix_get(dlm_lockspace_t *lockspace, u64 number, struct file *file,
> if (rv == -ENOENT)
> rv = 0;
> else if (rv > 0) {
> + locks_init_lock(fl);
> fl->fl_type = (op->info.ex) ? F_WRLCK : F_RDLCK;
> + fl->fl_flags = FL_POSIX;
> fl->fl_pid = op->info.pid;
> fl->fl_start = op->info.start;
> fl->fl_end = op->info.end;
> --
> 1.5.5.6
>
> _______________________________________________
> NFSv4 mailing list
> NFSv4@linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
next prev parent reply other threads:[~2009-01-21 23:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-21 16:34 [PATCH 0/2] nfsd/dlm: fix knfsd panic when NFSv4 client does GETLK call on GFS2 (regression) Jeff Layton
[not found] ` <1232555691-29859-1-git-send-email-jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-01-21 16:34 ` [PATCH 1/2] dlm: initialize file_lock struct in GETLK before copying conflicting lock Jeff Layton
2009-01-21 23:42 ` J. Bruce Fields [this message]
2009-01-22 2:26 ` Jeff Layton
2009-01-22 18:32 ` J. Bruce Fields
2009-01-22 18:37 ` Jeff Layton
2009-01-22 18:05 ` [Cluster-devel] " David Teigland
2009-01-22 18:37 ` Jeff Layton
[not found] ` <20090122133733.5d692a09-xSBYVWDuneFaJnirhKH9O4GKTjYczspe@public.gmane.org>
2009-01-22 19:03 ` David Teigland
2009-01-22 18:48 ` J. Bruce Fields
2009-01-21 16:34 ` [PATCH 2/2] nfsd: only set file_lock.fl_lmops in nfsd4_lockt if a stateowner is found Jeff Layton
2009-01-22 18:52 ` J. Bruce Fields
2009-01-22 18:58 ` Jeff Layton
[not found] ` <20090122135838.7aa9d9f3-xSBYVWDuneFaJnirhKH9O4GKTjYczspe@public.gmane.org>
2009-01-22 19:12 ` J. Bruce Fields
2009-01-22 18:59 ` Jeff Layton
2009-01-22 19:09 ` Jeff Layton
[not found] ` <20090122140902.0cedf21b-xSBYVWDuneFaJnirhKH9O4GKTjYczspe@public.gmane.org>
2009-01-22 19:15 ` J. Bruce Fields
-- strict thread matches above, loose matches on Subject: below --
2009-01-22 19:16 [PATCH 0/2] nfsd/dlm: fix knfsd panic when NFSv4 client does GETLK call Jeff Layton
2009-01-22 19:16 ` [PATCH 1/2] dlm: initialize file_lock struct in GETLK before copying conflicting lock Jeff Layton
[not found] ` <1232651764-10799-2-git-send-email-jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-01-27 22:34 ` J. Bruce Fields
2009-01-27 23:30 ` Jeff Layton
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=20090121234239.GM4295@fieldses.org \
--to=bfields@fieldses.org \
--cc=cluster-devel@redhat.com \
--cc=jlayton@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=lkml@vger.kernel.org \
--cc=nfsv4@linux-nfs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).