[lkml]   [2009]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[PATCH 0/2] 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 <>
    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(-)

     \ /
      Last update: 2009-01-22 20:19    [W:0.052 / U:2.616 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site