FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Cluster Development

LinkBack Thread Tools
Old 01-22-2009, 06:16 PM
Jeff Layton
Default nfsd/dlm: fix knfsd panic when NFSv4 client does GETLK call

This patchset fixes a regression due to this patch:

commit 55ef1274dddd4de387c54d110e354ffbb6cdc706
Author: J. Bruce Fields <bfields@citi.umich.edu>
Date: Sat Dec 20 11:58:38 2008 -0800

nfsd: Ensure nfsv4 calls the underlying filesystem on LOCKT

To reproduce, set up a nfs server that is serving out a GFS2 filesystem.
Set a lock locally on a file on the GFS2 export on the server. From a
NFSv4 client, do a GETLK against the same file. The server will oops due
to a NULL pointer dereference. The fl_lmops will be set, but the
fl_owner will be a NULL pointer. The knfsd code does not account for
this possibility. It assumes that when fl_lmops is set this way that
the fl_owner will point to a valid nfs4_stateowner struct.

In actuality, Bruce's patch is correct, but it exposes a bug in DLM's
GETLK codepath. The first patch in this set fixes that.

The second patch fixes knfsd to be a little more careful about the
file_lock struct it builds to pass to vfs_test_lock.

Either patch should prevent the panic, though I think applying both
patches is the best approach to fixing this.

Jeff Layton (2):
dlm: initialize file_lock struct in GETLK before copying conflicting
nfsd: only set file_lock.fl_lmops in nfsd4_lockt if a stateowner is

fs/dlm/plock.c | 2 ++
fs/nfsd/nfs4state.c | 1 -
2 files changed, 2 insertions(+), 1 deletions(-)

Thread Tools

All times are GMT. The time now is 11:59 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org