RE: [PATCH 0/4] locks: avoid thundering-herd wake-ups

> On Wed, Aug 08, 2018 at 03:54:45PM -0400, J. Bruce Fields wrote: > > On Wed, Aug 08, 2018 at 11:51:07AM +1000, NeilBrown wrote: > > > If you have a many-core machine, and have many threads all wanting > > > to briefly lock a give file (udev is known to do this), you can get > > > quite poor

RE: [PATCH 0/4] locks: avoid thundering-herd wake-ups

> On Wed, Aug 08, 2018 at 03:54:45PM -0400, J. Bruce Fields wrote: > > On Wed, Aug 08, 2018 at 11:51:07AM +1000, NeilBrown wrote: > > > If you have a many-core machine, and have many threads all wanting > > > to briefly lock a give file (udev is known to do this), you can get > > > quite poor

RE: [PATCH 0/4] locks: avoid thundering-herd wake-ups

> On Wed, 2018-08-08 at 17:28 -0400, J. Bruce Fields wrote: > > On Wed, Aug 08, 2018 at 04:09:12PM -0400, J. Bruce Fields wrote: > > > On Wed, Aug 08, 2018 at 03:54:45PM -0400, J. Bruce Fields wrote: > > > > On Wed, Aug 08, 2018 at 11:51:07AM +1000, NeilBrown wrote: > > > > > If you have a

RE: [PATCH 0/4] locks: avoid thundering-herd wake-ups

> On Wed, 2018-08-08 at 17:28 -0400, J. Bruce Fields wrote: > > On Wed, Aug 08, 2018 at 04:09:12PM -0400, J. Bruce Fields wrote: > > > On Wed, Aug 08, 2018 at 03:54:45PM -0400, J. Bruce Fields wrote: > > > > On Wed, Aug 08, 2018 at 11:51:07AM +1000, NeilBrown wrote: > > > > > If you have a

RE: [PATCH 1/2] fs: Check f_cred instead of current's creds in should_remove_suid()

> On Wed, Jan 25, 2017 at 1:43 PM, Ben Hutchings > wrote: > > On Wed, 2017-01-25 at 13:06 -0800, Andy Lutomirski wrote: > >> If an unprivileged program opens a setgid file for write and passes > >> the fd to a privileged program and the privileged program writes to > >> it,

RE: [PATCH 1/2] fs: Check f_cred instead of current's creds in should_remove_suid()

> On Wed, Jan 25, 2017 at 1:43 PM, Ben Hutchings > wrote: > > On Wed, 2017-01-25 at 13:06 -0800, Andy Lutomirski wrote: > >> If an unprivileged program opens a setgid file for write and passes > >> the fd to a privileged program and the privileged program writes to > >> it, we currently fail to

RE: [PATCH 2/2] fs: Harden against open(..., O_CREAT, 02777) in a setgid directory

> Currently, if you open("foo", O_WRONLY | O_CREAT | ..., 02777) in a > directory that is setgid and owned by a different gid than current's fsgid, you > end up with an SGID executable that is owned by the directory's GID. This is > a Bad Thing (tm). Exploiting this is nontrivial because most

RE: [PATCH 2/2] fs: Harden against open(..., O_CREAT, 02777) in a setgid directory

> Currently, if you open("foo", O_WRONLY | O_CREAT | ..., 02777) in a > directory that is setgid and owned by a different gid than current's fsgid, you > end up with an SGID executable that is owned by the directory's GID. This is > a Bad Thing (tm). Exploiting this is nontrivial because most

RE: [PATCH v23 08/22] richacl: Compute maximum file masks from an acl

> > Hmm, but does that result in examining the whole ACL for most access > checks, at least for files where most of the accesses are by the owner, or a > member of a specific group (with perhaps a ton of special case users added > on the end)? > > I don't understand -- what does this algorithm

RE: [PATCH v23 08/22] richacl: Compute maximum file masks from an acl

> > Hmm, but does that result in examining the whole ACL for most access > checks, at least for files where most of the accesses are by the owner, or a > member of a specific group (with perhaps a ton of special case users added > on the end)? > > I don't understand -- what does this algorithm

RE: [PATCH v23 08/22] richacl: Compute maximum file masks from an acl

> > + * Note: functions like richacl_allowed_to_who(), > > +richacl_group_class_allowed(), > > + * and richacl_compute_max_masks() iterate through the entire acl in > > +reverse > > + * order as an optimization. > > + * > > + * In the standard algorithm, aces are considered in forward order. > >

RE: [PATCH v23 08/22] richacl: Compute maximum file masks from an acl

> > + * Note: functions like richacl_allowed_to_who(), > > +richacl_group_class_allowed(), > > + * and richacl_compute_max_masks() iterate through the entire acl in > > +reverse > > + * order as an optimization. > > + * > > + * In the standard algorithm, aces are considered in forward order. > >

RE: [RFC v3 42/45] nfs: Add richacl support

> First, let me say thanks for all the work! We (Primary Data) have been using > samba with the vfs_richacl module reexporting an nfsv4.2 mount and things > are working pretty well. You can count on us for testing, bug fixing and code > review. > > Now for my question: It looks like this call to

RE: [RFC v3 42/45] nfs: Add richacl support

> First, let me say thanks for all the work! We (Primary Data) have been using > samba with the vfs_richacl module reexporting an nfsv4.2 mount and things > are working pretty well. You can count on us for testing, bug fixing and code > review. > > Now for my question: It looks like this call to

RE: [PATCH v21 00/22] Richacls

> On Tue, May 10, 2016 at 06:18:10AM +0200, Volker Lendecke wrote: > > On Tue, May 10, 2016 at 12:02:33AM +0200, Andreas Gruenbacher wrote: > > > What more can I do to finally get this merged? > > > > While I am not the one to comment on kernel specifics, from a pure > > Samba user space

RE: [PATCH v21 00/22] Richacls

> On Tue, May 10, 2016 at 06:18:10AM +0200, Volker Lendecke wrote: > > On Tue, May 10, 2016 at 12:02:33AM +0200, Andreas Gruenbacher wrote: > > > What more can I do to finally get this merged? > > > > While I am not the one to comment on kernel specifics, from a pure > > Samba user space

RE: [PATCH v12 00/49] Richacls

Andreas Gruenbacher: > > Here is another update of the richacl patch queue. I would like to ask for > feedback so that the core and local filesystem code (patches 1-25) can be > merged in the 4.4 merge window. > > Changes since the last posting (http://lwn.net/Articles/661078/): > > * On

RE: [PATCH v12 00/49] Richacls

Andreas Gruenbacher: > > Here is another update of the richacl patch queue. I would like to ask for > feedback so that the core and local filesystem code (patches 1-25) can be > merged in the 4.4 merge window. > > Changes since the last posting (http://lwn.net/Articles/661078/): > > * On

RE: [PATCH] NFSv4: handle nfs4_get_referral failure

More detail on this, Basically what is going on is that a migration event has been detected in nfs4_get_referral, but the migration recovery is not actually initiated. We tripped over this because Ganesha intends to support referrals, but the implementation is incomplete (not all FSALs support

RE: [PATCH] NFSv4: handle nfs4_get_referral failure

More detail on this, Basically what is going on is that a migration event has been detected in nfs4_get_referral, but the migration recovery is not actually initiated. We tripped over this because Ganesha intends to support referrals, but the implementation is incomplete (not all FSALs support

RE: [RFC v3 42/45] nfs: Add richacl support

> On Fri, May 29, 2015 at 11:00 AM, Andreas Grünbacher > wrote: > > 2015-05-29 15:15 GMT+02:00 Trond Myklebust > : > >> [reply reordered] > >> So having revisited the reasons why I chose the system.nfs4_acl > >> interface when we did NFSv4 ACLs, I'm not sure we should implement > >>

RE: [RFC v3 42/45] nfs: Add richacl support

On Fri, May 29, 2015 at 11:00 AM, Andreas Grünbacher andreas.gruenbac...@gmail.com wrote: 2015-05-29 15:15 GMT+02:00 Trond Myklebust trond.mykleb...@primarydata.com: [reply reordered] So having revisited the reasons why I chose the system.nfs4_acl interface when we did NFSv4 ACLs, I'm

RE: [RFC v3 20/45] richacl: Automatic Inheritance

> -Original Message- > From: Andreas Grünbacher [mailto:andreas.gruenbac...@gmail.com] > Sent: Wednesday, May 13, 2015 2:06 PM > To: Frank Filz > Cc: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; linux- > n...@vger.kernel.org > Subject: Re: [

RE: [RFC v3 20/45] richacl: Automatic Inheritance

> -Original Message- > From: Andreas Grünbacher [mailto:andreas.gruenbac...@gmail.com] > Sent: Wednesday, May 13, 2015 1:22 PM > To: Frank Filz > Cc: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; linux- > n...@vger.kernel.org > Subject: Re: [

RE: [RFC v3 20/45] richacl: Automatic Inheritance

> -Original Message- > From: linux-nfs-ow...@vger.kernel.org [mailto:linux-nfs- > ow...@vger.kernel.org] On Behalf Of Andreas Gruenbacher > Sent: Friday, April 24, 2015 4:04 AM > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; linux- > n...@vger.kernel.org > Subject:

RE: [RFC v3 20/45] richacl: Automatic Inheritance

-Original Message- From: Andreas Grünbacher [mailto:andreas.gruenbac...@gmail.com] Sent: Wednesday, May 13, 2015 1:22 PM To: Frank Filz Cc: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; linux- n...@vger.kernel.org Subject: Re: [RFC v3 20/45] richacl: Automatic

RE: [RFC v3 20/45] richacl: Automatic Inheritance

-Original Message- From: Andreas Grünbacher [mailto:andreas.gruenbac...@gmail.com] Sent: Wednesday, May 13, 2015 2:06 PM To: Frank Filz Cc: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; linux- n...@vger.kernel.org Subject: Re: [RFC v3 20/45] richacl: Automatic

RE: [RFC v3 20/45] richacl: Automatic Inheritance

-Original Message- From: linux-nfs-ow...@vger.kernel.org [mailto:linux-nfs- ow...@vger.kernel.org] On Behalf Of Andreas Gruenbacher Sent: Friday, April 24, 2015 4:04 AM To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; linux- n...@vger.kernel.org Subject: [RFC v3

RE: [PATCH 1/1] Fix permission checking by NFS client for open-create with mode 000

> >> >> Oops. Sorry, the correct sub-sub-sub-sub-paragraph is this one: > >> >> > >> >> Permission to execute a file. > >> >> > >> >> Servers SHOULD allow a user the ability to read the data of the > >> >> file when only the ACE4_EXECUTE access mask bit is allowed. >

RE: [PATCH 1/1] Fix permission checking by NFS client for open-create with mode 000

Oops. Sorry, the correct sub-sub-sub-sub-paragraph is this one: Permission to execute a file. Servers SHOULD allow a user the ability to read the data of the file when only the ACE4_EXECUTE access mask bit is allowed. This is because

RE: [PATCH 1/1] Fix permission checking by NFS client for open-create with mode 000

> On Thu, Jul 10, 2014 at 12:26 AM, Frank Filz > wrote: > >> On Wed, Jul 9, 2014 at 7:06 PM, Trond Myklebust > >> wrote: > >> > On Wed, Jul 9, 2014 at 6:42 PM, Frank Filz > >> > > >> wrote: > >> >>> On Wed, Jul 9, 2014

RE: [PATCH 1/1] Fix permission checking by NFS client for open-create with mode 000

> On Wed, Jul 9, 2014 at 7:06 PM, Trond Myklebust > wrote: > > On Wed, Jul 9, 2014 at 6:42 PM, Frank Filz > wrote: > >>> On Wed, Jul 9, 2014 at 5:54 PM, Frank S. Filz > >>> > >>> wrote: > >>> > From: "Frank S. Filz" &

RE: [PATCH 1/1] Fix permission checking by NFS client for open-create with mode 000

> On Wed, Jul 9, 2014 at 5:54 PM, Frank S. Filz > wrote: > > From: "Frank S. Filz" > > > > The NFS v4 client sends a COMPOUND with an OPEN and an ACCESS. > > > > The ACCESS is required to verify an open for read is actually allowed > > because RFC 3530 indicates OPEN for read only must succeed

RE: [PATCH 1/1] Fix permission checking by NFS client for open-create with mode 000

On Wed, Jul 9, 2014 at 5:54 PM, Frank S. Filz ffilz...@mindspring.com wrote: From: Frank S. Filz ffilz...@mindspring.com The NFS v4 client sends a COMPOUND with an OPEN and an ACCESS. The ACCESS is required to verify an open for read is actually allowed because RFC 3530 indicates

RE: [PATCH 1/1] Fix permission checking by NFS client for open-create with mode 000

On Wed, Jul 9, 2014 at 7:06 PM, Trond Myklebust trond.mykleb...@primarydata.com wrote: On Wed, Jul 9, 2014 at 6:42 PM, Frank Filz ffilz...@mindspring.com wrote: On Wed, Jul 9, 2014 at 5:54 PM, Frank S. Filz ffilz...@mindspring.com wrote: From: Frank S. Filz ffilz...@mindspring.com

RE: [PATCH 1/1] Fix permission checking by NFS client for open-create with mode 000

On Thu, Jul 10, 2014 at 12:26 AM, Frank Filz ffilz...@mindspring.com wrote: On Wed, Jul 9, 2014 at 7:06 PM, Trond Myklebust trond.mykleb...@primarydata.com wrote: On Wed, Jul 9, 2014 at 6:42 PM, Frank Filz ffilz...@mindspring.com wrote: On Wed, Jul 9, 2014 at 5:54 PM, Frank S

RE: OFD ("file private") locks and NFS

> On Tue, 29 Apr 2014 07:40:08 -0400 (EDT) "Matt W. Benjamin" > wrote: > > > Hi Jeff, > > > > Something which came up on the last Ganesha conn call is that we have > > a pretty strong need for some ability to wait on a set of locks, and > > perh

RE: OFD (file private) locks and NFS

On Tue, 29 Apr 2014 07:40:08 -0400 (EDT) Matt W. Benjamin m...@linuxbox.com wrote: Hi Jeff, Something which came up on the last Ganesha conn call is that we have a pretty strong need for some ability to wait on a set of locks, and perhaps receive events. Frank Filz believed that you

RE: [Nfs-ganesha-devel] [PATCH] locks: rename file-private locks to file-description locks

> On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages) > wrote: > > > > There's at least two problems to solve here: > > > > 1) "File private locks" is _meaningless_ as a term. Elsewhere > > > > > (http://thread.gmane.org/gmane.network.samba.internals/76414/focus=16 > 8 > > 5376),

RE: [Nfs-ganesha-devel] [PATCH] locks: rename file-private locks to file-description locks

On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages) wrote: There's at least two problems to solve here: 1) File private locks is _meaningless_ as a term. Elsewhere (http://thread.gmane.org/gmane.network.samba.internals/76414/focus=16 8 5376), It's indeed not

RE: [Nfs-ganesha-devel] name_to_handle_at() and persistent filesystem IDs

> Michael Kerrisk writes: > > > Hello Aneesh, > > > > I'm currently working on a man page for name_to_handle_at() and > > open_by_handle_at(), and I have a question relating to a point that > > probably needs to be covered in the man page. > > > > Back in July 2010, in this thread: > >

RE: [Nfs-ganesha-devel] name_to_handle_at() and persistent filesystem IDs

Michael Kerrisk mtk.manpa...@gmail.com writes: Hello Aneesh, I'm currently working on a man page for name_to_handle_at() and open_by_handle_at(), and I have a question relating to a point that probably needs to be covered in the man page. Back in July 2010, in this thread:

RE: [PATCH v7 0/7] Add O_DENY* support for VFS and CIFS/NFS

> 2014/1/17 Frank Filz : > > This looks wonderful and will be useful to the Ganesha user space NFS > > server also. > > > > I do have a couple questions. > > > > 1. How will this interact with the idea of private locks from the > > patch set Jeff Layton

RE: [PATCH v7 0/7] Add O_DENY* support for VFS and CIFS/NFS

2014/1/17 Frank Filz ffilz...@mindspring.com: This looks wonderful and will be useful to the Ganesha user space NFS server also. I do have a couple questions. 1. How will this interact with the idea of private locks from the patch set Jeff Layton has been pushing? They don't

RE: [PATCH v7 0/7] Add O_DENY* support for VFS and CIFS/NFS

This looks wonderful and will be useful to the Ganesha user space NFS server also. I do have a couple questions. 1. How will this interact with the idea of private locks from the patch set Jeff Layton has been pushing? 2. If a process opens multiple file descriptors with deny modes, will they

RE: [PATCH v7 0/7] Add O_DENY* support for VFS and CIFS/NFS

This looks wonderful and will be useful to the Ganesha user space NFS server also. I do have a couple questions. 1. How will this interact with the idea of private locks from the patch set Jeff Layton has been pushing? 2. If a process opens multiple file descriptors with deny modes, will they

RE: [PATCH v5 13/14] locks: skip deadlock detection on FL_FILE_PVT locks

> [grr, gmail -- I didn't actually intend to send that.] > > On Tue, Jan 14, 2014 at 1:24 PM, Andy Lutomirski > wrote: > > On Tue, Jan 14, 2014 at 1:19 PM, Frank Filz > wrote: > >>> process 2 requests a write lock, gets -EDEADLK, unlocks and >

RE: [PATCH v5 13/14] locks: skip deadlock detection on FL_FILE_PVT locks

> On Tue, Jan 14, 2014 at 12:29:17PM -0800, Andy Lutomirski wrote: > > [cc: drh, who I suspect is responsible for the most widespread > > userspace software that uses this stuff] > > > > On Tue, Jan 14, 2014 at 11:27 AM, J. Bruce Fields > wrote: > > > On Thu, Jan 09, 2014 at 04:58:59PM -0800,

RE: [PATCH v5 13/14] locks: skip deadlock detection on FL_FILE_PVT locks

On Tue, Jan 14, 2014 at 12:29:17PM -0800, Andy Lutomirski wrote: [cc: drh, who I suspect is responsible for the most widespread userspace software that uses this stuff] On Tue, Jan 14, 2014 at 11:27 AM, J. Bruce Fields bfie...@fieldses.org wrote: On Thu, Jan 09, 2014 at 04:58:59PM

RE: [PATCH v5 13/14] locks: skip deadlock detection on FL_FILE_PVT locks

[grr, gmail -- I didn't actually intend to send that.] On Tue, Jan 14, 2014 at 1:24 PM, Andy Lutomirski l...@amacapital.net wrote: On Tue, Jan 14, 2014 at 1:19 PM, Frank Filz ffilz...@mindspring.com wrote: process 2 requests a write lock, gets -EDEADLK, unlocks and requests

RE: [Nfs-ganesha-devel] [PATCH v3 5/6] locks: report l_pid as -1 for FL_FILE_PVT locks

> On Tue, 10 Dec 2013 14:17:34 -0500 > Jeff Layton wrote: > > > FL_FILE_PVT locks are no longer tied to a particular pid, and are > > instead inheritable by child processes. Report a l_pid of '-1' for > > these sorts of locks since the pid is somewhat meaningless for them. > > > > This precedent

RE: [Nfs-ganesha-devel] [PATCH v3 0/6] locks: implement "filp-private" (aka UNPOSIX) locks

> This patchset is the third posting of this set. Behavior between this set and > the last should be more or less the same. Here is a summary of > changes: > > v3: > - more consolidation of common code between flock_to_posix_lock and > flock_to_posix_lock64 > - better bisectability by

RE: [Nfs-ganesha-devel] [PATCH v3 0/6] locks: implement filp-private (aka UNPOSIX) locks

This patchset is the third posting of this set. Behavior between this set and the last should be more or less the same. Here is a summary of changes: v3: - more consolidation of common code between flock_to_posix_lock and flock_to_posix_lock64 - better bisectability by reordering

RE: [Nfs-ganesha-devel] [PATCH v3 5/6] locks: report l_pid as -1 for FL_FILE_PVT locks

On Tue, 10 Dec 2013 14:17:34 -0500 Jeff Layton jlay...@redhat.com wrote: FL_FILE_PVT locks are no longer tied to a particular pid, and are instead inheritable by child processes. Report a l_pid of '-1' for these sorts of locks since the pid is somewhat meaningless for them. This

RE: [RFC PATCH v2 5/5] locks: report l_pid as -1 for FL_FILP_PRIVATE locks

> FL_FILP_PRIVATE locks are no longer tied to a particular PID, and are instead > inheritable by child processes. Report a l_pid of '-1' for these sorts of locks > since the pid is somewhat meaningless for them. Hmm, I suppose in the case of a process that acquires a private lock, forks (passing

RE: [RFC PATCH v2 5/5] locks: report l_pid as -1 for FL_FILP_PRIVATE locks

FL_FILP_PRIVATE locks are no longer tied to a particular PID, and are instead inheritable by child processes. Report a l_pid of '-1' for these sorts of locks since the pid is somewhat meaningless for them. Hmm, I suppose in the case of a process that acquires a private lock, forks (passing the

RE: [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX) locks

> http://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2 > > > .html > > > > > > See the section entitled "First Implementation Past the Post". > > > > Interesting that Jeremy actually suggested the implementation should > > have had an arbitrary lock owner as part of the flock

RE: [RFC PATCH 0/5] locks: implement filp-private (aka UNPOSIX) locks

http://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2 .html See the section entitled First Implementation Past the Post. Interesting that Jeremy actually suggested the implementation should have had an arbitrary lock owner as part of the flock structure: This is

RE: [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX) locks

> This blog post of Jeremy's explains some of the history: > > > http://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2 > .html > > See the section entitled "First Implementation Past the Post". Interesting that Jeremy actually suggested the implementation should have had an

RE: [Nfs-ganesha-devel] [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX) locks

> > > At LSF this year, there was a discussion about the "wishlist" for > > > userland file servers. One of the things brought up was the goofy > > > and problematic behavior of POSIX locks when a file is closed. Boaz > > > started a thread on it here: > > > > > >

RE: [Nfs-ganesha-devel] [RFC PATCH 0/5] locks: implement filp-private (aka UNPOSIX) locks

At LSF this year, there was a discussion about the wishlist for userland file servers. One of the things brought up was the goofy and problematic behavior of POSIX locks when a file is closed. Boaz started a thread on it here:

RE: [RFC PATCH 0/5] locks: implement filp-private (aka UNPOSIX) locks

This blog post of Jeremy's explains some of the history: http://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2 .html See the section entitled First Implementation Past the Post. Interesting that Jeremy actually suggested the implementation should have had an arbitrary

RE: [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX) locks

> > > > > > At LSF this year, there was a discussion about the "wishlist" > > > > > > for userland file servers. One of the things brought up was > > > > > > the goofy and problematic behavior of POSIX locks when a file is > closed. > > > > > > Boaz started a thread on it here: > > > > > > > > > >

RE: [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX) locks

> > > > At LSF this year, there was a discussion about the "wishlist" for > > > > userland file servers. One of the things brought up was the goofy > > > > and problematic behavior of POSIX locks when a file is closed. > > > > Boaz started a thread on it here: > > > > > > > >

RE: [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX) locks

> > At LSF this year, there was a discussion about the "wishlist" for > > userland file servers. One of the things brought up was the goofy and > > problematic behavior of POSIX locks when a file is closed. Boaz > > started a thread on it here: > > > >

RE: [RFC PATCH 0/5] locks: implement filp-private (aka UNPOSIX) locks

At LSF this year, there was a discussion about the wishlist for userland file servers. One of the things brought up was the goofy and problematic behavior of POSIX locks when a file is closed. Boaz started a thread on it here:

RE: [RFC PATCH 0/5] locks: implement filp-private (aka UNPOSIX) locks

At LSF this year, there was a discussion about the wishlist for userland file servers. One of the things brought up was the goofy and problematic behavior of POSIX locks when a file is closed. Boaz started a thread on it here:

RE: [RFC PATCH 0/5] locks: implement filp-private (aka UNPOSIX) locks

At LSF this year, there was a discussion about the wishlist for userland file servers. One of the things brought up was the goofy and problematic behavior of POSIX locks when a file is closed. Boaz started a thread on it here:

Re: [PATCH v5 1/7] fcntl: Introduce new O_DENY* open flags

linux-nfs-ow...@vger.kernel.org wrote on 04/10/2013 06:24:39 AM: > 2013/4/10 Jeff Layton : > > On Tue, 9 Apr 2013 16:40:21 +0400 > > Pavel Shilovsky wrote: > > > >> This patch adds 3 flags: > >> 1) O_DENYREAD that doesn't permit read access, > >> 2) O_DENYWRITE that doesn't permit write access,