lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140427200431.426c98d1@notabene.brown>
Date:	Sun, 27 Apr 2014 20:04:31 +1000
From:	NeilBrown <neilb@...e.de>
To:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc:	"Stefan (metze) Metzmacher" <metze@...ba.org>,
	Jeff Layton <jlayton@...hat.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Ganesha NFS List <nfs-ganesha-devel@...ts.sourceforge.net>,
	Suresh Jayaraman <sjayaraman@...e.de>,
	Trond Myklebust <trond.myklebust@....uio.no>,
	Christoph Hellwig <hch@...radead.org>,
	linux-nfs@...r.kernel.org, "J. Bruce Fields" <bfields@...ldses.org>
Subject: Re: flock() and NFS [Was: Re: [PATCH] locks: rename file-private
 locks to file-description locks]

On Sun, 27 Apr 2014 11:16:02 +0200 "Michael Kerrisk (man-pages)"
<mtk.manpages@...il.com> wrote:

> [Trimming some folk from CC, and adding various NFS people]
> 
> On 04/27/2014 06:51 AM, NeilBrown wrote:
> 
> [...]
> 
> > Note to Michael: The text
> >    flock() does not lock files over NFS.
> > in flock(2) is no longer accurate.  The reality is ... complex.
> > See nfs(5), and search for "local_lock".
> 
> Ahhh -- I see: 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5eebde23223aeb0ad2d9e3be6590ff8bbfab0fc2
> 
> Thanks for the heads up.
> 
> Just in general, it would be great if the flock(2) and fcntl(2) man pages
> contained correct details for NFS, of course. So, for example, if there 
> are any current gotchas for NFS and fcntl() byte-range locking, I'd like 
> to add those to the fcntl(2) man page.

The only peculiarities I can think of are:
 - With NFS, locking or unlocking a region forces a flush of any cached data 
   for that file (or maybe for the region of the file).  I'm not sure if this
   is worth mentioning.

 - With NFSv4 the client can lose a lock if it is out of contact with the
   server for a period of time.  When this happens, any IO to the file by a
   process which "thinks" it holds a lock will fail until that process closes
   and re-opens the file.
   This behaviour is since 3.12.  Prior to that the client might lose and
   regain the lock without ever knowing thus potentially risking corruption
   (but only if client and server lost contact for an extended period).

> 
> Anyway, returning to your point about flock(), how would this text
> look for the flock(2) manual page:
> 
>     NOTES
>        Since  kernel  2.0,  flock() is implemented as a system call in
>        its own right rather than being emulated in the GNU  C  library
>        as  a  call  to fcntl(2).  This yields classical BSD semantics:
>        there is no interaction between the types  of  lock  placed  by
>        flock()  and  fcntl(2),  and  flock() does not detect deadlock.
>        (Note, however, that on some modern BSDs, flock() and  fcntl(2)
>        locks do interact with one another.)
> 
>        In Linux kernels up to 2.6.11, flock() does not lock files over
>        NFS (i.e., the scope of locks was limited to the local system).
>        Instead,  one could use fcntl(2) byte-range locking, which does
>        work over NFS, given a sufficiently recent version of Linux and
>        a  server  which  supports  locking.   Since  Linux 2.6.12, NFS
>        clients support flock() locks by emulating them  as  byte-range
>        locks on the entire file.  This means that fcntl(2) and flock()
>        locks do interact with  one  another  over  NFS.   Since  Linux
>        2.6.37,  the  kernel  supports a compatibility mode that allows
>        flock() locks (and also  fcntl(2)  byte  region  locks)  to  be
>        treated  as  local; see the discussion of the local_lock option
>        in nfs(5).
> ?

That seems to cover it quite well - thanks.

NeilBrown

> 
> Thanks,
> 
> Michael
> 
> 


Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ