Fcntl(..., F GETLK, ...) does not return correct info about a read lock which is set on server

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
(Created page with "== About == * Kernel version: 2.6.22-rc1 and higher * [https://bugzilla.kernel.org/show_bug.cgi?id=23892 Bug 23892] * Reported by: Alexander Morozov (November 28, 2010) * Fixed ...")
 
Line 3: Line 3:
* [https://bugzilla.kernel.org/show_bug.cgi?id=23892 Bug 23892]
* [https://bugzilla.kernel.org/show_bug.cgi?id=23892 Bug 23892]
* Reported by: Alexander Morozov (November 28, 2010)
* Reported by: Alexander Morozov (November 28, 2010)
-
* Fixed by: Florain Mickler (January 23, 2010)
+
* Fixed by: Sergey Vlasov (November 28, 2010)
 +
* Closed by: Florain Mickler (January 23, 2011)
Line 35: Line 36:
* The bug does not occur if client with 2.6.21 kernel.
* The bug does not occur if client with 2.6.21 kernel.
* The bug occurs if client with 2.6.22-rc1 and higher.
* The bug occurs if client with 2.6.22-rc1 and higher.
 +
 +
 +
== Resolution ==
 +
* This problem was fixed by commit [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=21ac19d484a8ffb66f64487846c8d53afef04d2b 21ac19d484a8ffb66f64487846c8d53afef04d2b]
 +
<pre>
 +
commit 21ac19d484a8ffb66f64487846c8d53afef04d2b
 +
Author: Sergey Vlasov <vsu@altlinux.ru>
 +
Date:  Sun Nov 28 21:04:05 2010 +0000
 +
 +
    NFS: Fix fcntl F_GETLK not reporting some conflicts
 +
   
 +
    The commit 129a84de2347002f09721cda3155ccfd19fade40 (locks: fix F_GETLK
 +
    regression (failure to find conflicts)) fixed the posix_test_lock()
 +
    function by itself, however, its usage in NFS changed by the commit
 +
    9d6a8c5c213e34c475e72b245a8eb709258e968c (locks: give posix_test_lock
 +
    same interface as ->lock) remained broken - subsequent NFS-specific
 +
    locking code received F_UNLCK instead of the user-specified lock type.
 +
    To fix the problem, fl->fl_type needs to be saved before the
 +
    posix_test_lock() call and restored if no local conflicts were reported.
 +
   
 +
    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=23892
 +
    Tested-by: Alexander Morozov <amorozov@etersoft.ru>
 +
    Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
 +
    Cc: <stable@kernel.org>
 +
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
 +
 +
</pre>

Latest revision as of 19:39, 29 July 2011

About

  • Kernel version: 2.6.22-rc1 and higher
  • Bug 23892
  • Reported by: Alexander Morozov (November 28, 2010)
  • Fixed by: Sergey Vlasov (November 28, 2010)
  • Closed by: Florain Mickler (January 23, 2011)


How to reproduce

  • Environment:
Debian Lenny with kernel 2.6.37-rc3 i686
nfs-common         1:1.1.2-6lenny2
nfs-kernel-server  1:1.1.2-6lenny2
172.22.0.10 is a server
172.22.0.11 is a client
  • /etc/exports on a server:
/srv/test  172.22.0.11(rw,sync,no_subtree_check)
  • Steps to reproduce:
client# mount -t nfs 172.22.0.10:/srv/test /srv/test

server$ cd /srv/test
server$ ./linlock r file
press Ctrl-C...

client$ cd /srv/test
client$ ./linlock w file
fcntl: Resource temporary unavailable
client$ ./lockinfo file
F_UNLCK SEEK_SET start 0 len 0
  • ./linlock tool set read (r) or write (w) lock on a file.
  • ./lockinfo shows what F_GETLK returns. This test shows that a client can not set a write lock on a read lock of server but F_GETLK tells that file is not locked.
  • The bug does not occur if client with 2.6.21 kernel.
  • The bug occurs if client with 2.6.22-rc1 and higher.


Resolution

commit 21ac19d484a8ffb66f64487846c8d53afef04d2b
Author: Sergey Vlasov <vsu@altlinux.ru>
Date:   Sun Nov 28 21:04:05 2010 +0000

    NFS: Fix fcntl F_GETLK not reporting some conflicts
    
    The commit 129a84de2347002f09721cda3155ccfd19fade40 (locks: fix F_GETLK
    regression (failure to find conflicts)) fixed the posix_test_lock()
    function by itself, however, its usage in NFS changed by the commit
    9d6a8c5c213e34c475e72b245a8eb709258e968c (locks: give posix_test_lock
    same interface as ->lock) remained broken - subsequent NFS-specific
    locking code received F_UNLCK instead of the user-specified lock type.
    To fix the problem, fl->fl_type needs to be saved before the
    posix_test_lock() call and restored if no local conflicts were reported.
    
    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=23892
    Tested-by: Alexander Morozov <amorozov@etersoft.ru>
    Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
    Cc: <stable@kernel.org>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

Personal tools