Re: [GIT PULL] more nfsd bugfixes for 4.3

Please pull two more nfsd bugfixes for 4.3 from: git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.3-2 Two nfsd fixes, one for an RDMA crash, one for a pnfs/block protocol bug. --b. Christoph Hellwig (1): nfsd/blocklayout: accept any minlength Chuck Lever (1): svcrdma: Fix NFS

Re: [GIT PULL] more nfsd bugfixes for 4.3

Please pull two more nfsd bugfixes for 4.3 from: git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.3-2 Two nfsd fixes, one for an RDMA crash, one for a pnfs/block protocol bug. --b. Christoph Hellwig (1): nfsd/blocklayout: accept any minlength Chuck Lever (1): svcrdma: Fix NFS

Re: [PATCH v2] sunrpc: fix waitqueue_active without memory barrier in sunrpc

On Mon, Oct 12, 2015 at 10:41:06AM +, Kosuke Tatsukawa wrote: > J. Bruce Fields wrote: > > On Fri, Oct 09, 2015 at 06:29:44AM +, Kosuke Tatsukawa wrote: > >> Neil Brown wrote: > >> > Kosuke Tatsukawa writes: > >> > > >> >> The

Re: [PATCH v2] sunrpc: fix waitqueue_active without memory barrier in sunrpc

On Mon, Oct 12, 2015 at 10:41:06AM +, Kosuke Tatsukawa wrote: > J. Bruce Fields wrote: > > On Fri, Oct 09, 2015 at 06:29:44AM +, Kosuke Tatsukawa wrote: > >> Neil Brown wrote: > >> > Kosuke Tatsukawa <ta...@ab.jp.nec.com> writes: > >> >

Re: [PATCH v2] sunrpc: fix waitqueue_active without memory barrier in sunrpc

On Fri, Oct 09, 2015 at 06:29:44AM +, Kosuke Tatsukawa wrote: > Neil Brown wrote: > > Kosuke Tatsukawa writes: > > > >> There are several places in net/sunrpc/svcsock.c which calls > >> waitqueue_active() without calling a memory barrier. Add a memory > >> barrier just as in

Re: [PATCH] sunrpc: avoid warning in gss_key_timeout

On Fri, Oct 09, 2015 at 04:13:45PM +0200, Arnd Bergmann wrote: > The gss_key_timeout() function causes a harmless warning in some > configurations, e.g. ARM imx_v6_v7_defconfig with gcc-5.2, if the > compiler cannot figure out the state of the 'expire' variable across > an rcu_read_unlock(): > >

Re: [PATCH v2] sunrpc: fix waitqueue_active without memory barrier in sunrpc

On Fri, Oct 09, 2015 at 06:29:44AM +, Kosuke Tatsukawa wrote: > Neil Brown wrote: > > Kosuke Tatsukawa writes: > > > >> There are several places in net/sunrpc/svcsock.c which calls > >> waitqueue_active() without calling a memory barrier. Add a memory > >> barrier just

Re: [PATCH] sunrpc: avoid warning in gss_key_timeout

On Fri, Oct 09, 2015 at 04:13:45PM +0200, Arnd Bergmann wrote: > The gss_key_timeout() function causes a harmless warning in some > configurations, e.g. ARM imx_v6_v7_defconfig with gcc-5.2, if the > compiler cannot figure out the state of the 'expire' variable across > an rcu_read_unlock(): > >

Re: [PATCH v2] lockd: get rid of reference-counted NSM RPC clients

On Wed, Oct 07, 2015 at 05:45:15PM -0400, Trond Myklebust wrote: > On Wed, Oct 7, 2015 at 7:39 AM, Andrey Ryabinin > wrote: > > Currently we have reference-counted per-net NSM RPC client > > which created on the first monitor request and destroyed > > after the last unmonitor request. It's

Re: [PATCH v2] lockd: get rid of reference-counted NSM RPC clients

On Wed, Oct 07, 2015 at 05:45:15PM -0400, Trond Myklebust wrote: > On Wed, Oct 7, 2015 at 7:39 AM, Andrey Ryabinin > wrote: > > Currently we have reference-counted per-net NSM RPC client > > which created on the first monitor request and destroyed > > after the last

Re: [PATCH v2] lockd: get rid of reference-counted NSM RPC clients

On Wed, Oct 07, 2015 at 02:39:55PM +0300, Andrey Ryabinin wrote: > Currently we have reference-counted per-net NSM RPC client > which created on the first monitor request and destroyed > after the last unmonitor request. It's needed because > RPC client need to know 'utsname()->nodename', but

[GIT PULL] nfsd bugfix for 4.3

Please pull an nfsd bugfix for 4.3 from: git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.3-1 Just this one RDMA fix for now.--b. Steve Wise (1): svcrdma: handle rdma read with a non-zero initial page offset net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 6 -- 1 file changed, 4

Re: [PATCH v2] lockd: get rid of reference-counted NSM RPC clients

On Wed, Oct 07, 2015 at 02:39:55PM +0300, Andrey Ryabinin wrote: > Currently we have reference-counted per-net NSM RPC client > which created on the first monitor request and destroyed > after the last unmonitor request. It's needed because > RPC client need to know 'utsname()->nodename', but

[GIT PULL] nfsd bugfix for 4.3

Please pull an nfsd bugfix for 4.3 from: git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.3-1 Just this one RDMA fix for now.--b. Steve Wise (1): svcrdma: handle rdma read with a non-zero initial page offset net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 6 -- 1 file changed, 4

Re: [PATCH] lockd: create NSM handles per net namespace

On Thu, Oct 01, 2015 at 07:36:19PM +0300, Andrey Ryabinin wrote: > On 09/29/2015 09:47 PM, J. Bruce Fields wrote: > > On Wed, Sep 23, 2015 at 03:49:29PM +0300, Andrey Ryabinin wrote: > >> Commit cb7323fffa85 ("lockd: create and use per-net NSM > >> RPC clients on

Re: [PATCH] lockd: create NSM handles per net namespace

On Thu, Oct 01, 2015 at 07:36:19PM +0300, Andrey Ryabinin wrote: > On 09/29/2015 09:47 PM, J. Bruce Fields wrote: > > On Wed, Sep 23, 2015 at 03:49:29PM +0300, Andrey Ryabinin wrote: > >> Commit cb7323fffa85 ("lockd: create and use per-net NSM > >> RPC clients on

Re: [lkp] [nfsd] 4aac1bf05b: -2.9% fsmark.files_per_sec

On Thu, Oct 01, 2015 at 09:17:42AM +1000, Dave Chinner wrote: > Inode pointers have no entropy in the lower 9-10 bits because of > their size, and being allocated from a slab they are all going to > have the same set of values in the next 3-4 bits (i.e. offset into > the slab page which is defined

Re: [lkp] [nfsd] 4aac1bf05b: -2.9% fsmark.files_per_sec

On Thu, Oct 01, 2015 at 09:17:42AM +1000, Dave Chinner wrote: > Inode pointers have no entropy in the lower 9-10 bits because of > their size, and being allocated from a slab they are all going to > have the same set of values in the next 3-4 bits (i.e. offset into > the slab page which is defined

Re: [PATCH] lockd: create NSM handles per net namespace

On Wed, Sep 23, 2015 at 03:49:29PM +0300, Andrey Ryabinin wrote: > Commit cb7323fffa85 ("lockd: create and use per-net NSM > RPC clients on MON/UNMON requests") introduced per-net > NSM RPC clients. Unfortunately this doesn't make any sense > without per-net nsm_handle. Makes sense to me. Is

Re: [PATCH] lockd: create NSM handles per net namespace

On Wed, Sep 23, 2015 at 03:49:29PM +0300, Andrey Ryabinin wrote: > Commit cb7323fffa85 ("lockd: create and use per-net NSM > RPC clients on MON/UNMON requests") introduced per-net > NSM RPC clients. Unfortunately this doesn't make any sense > without per-net nsm_handle. Makes sense to me. Is

Re: [PATCH v8 00/41] Richacls

On Mon, Sep 28, 2015 at 07:10:06PM +0200, Andreas Grünbacher wrote: > 2015-09-28 18:35 GMT+02:00 J. Bruce Fields : > > On Mon, Sep 28, 2015 at 12:08:51AM +0200, Andreas Gruenbacher wrote: > >> Open issues in nfs: > >> > >> * When a user or group name cannot b

Re: [PATCH v8 00/41] Richacls

On Mon, Sep 28, 2015 at 12:08:51AM +0200, Andreas Gruenbacher wrote: > here's another update of the richacl patch queue. At this stage, I would > like to ask for final feedback so that the core and ext4 code (patches > 1-19) can be merged in the 4.4 merge window. The nfsd and nfs code should >

Re: [PATCH v8 10/41] richacl: Permission check algorithm

On Mon, Sep 28, 2015 at 06:25:23PM +0200, Andreas Grünbacher wrote: > 2015-09-28 18:08 GMT+02:00 J. Bruce Fields : > > On Mon, Sep 28, 2015 at 12:09:01AM +0200, Andreas Gruenbacher wrote: > >> + /* > >> + * Check if the acl grants the requested

Re: [PATCH v8 10/41] richacl: Permission check algorithm

gt; includes the requested permissions. > > Signed-off-by: Andreas Gruenbacher > Reviewed-by: "J. Bruce Fields" > --- > fs/Makefile | 2 +- > fs/richacl_inode.c | 148 > > include/linux/richacl.h |

Re: [PATCH v8 09/41] richacl: Update the file masks in chmod()

n. > > Signed-off-by: Andreas Gruenbacher > Reviewed-by: J. Bruce Fields > --- > fs/richacl_base.c | 40 > include/linux/richacl.h | 1 + > 2 files changed, 41 insertions(+) > > diff --git a/fs/richacl_base.c b/fs/richacl_bas

Re: [PATCH v8 00/41] Richacls

On Mon, Sep 28, 2015 at 12:08:51AM +0200, Andreas Gruenbacher wrote: > here's another update of the richacl patch queue. At this stage, I would > like to ask for final feedback so that the core and ext4 code (patches > 1-19) can be merged in the 4.4 merge window. The nfsd and nfs code should >

Re: [PATCH v8 00/41] Richacls

On Mon, Sep 28, 2015 at 07:10:06PM +0200, Andreas Grünbacher wrote: > 2015-09-28 18:35 GMT+02:00 J. Bruce Fields <bfie...@fieldses.org>: > > On Mon, Sep 28, 2015 at 12:08:51AM +0200, Andreas Gruenbacher wrote: > >> Open issues in nfs: > >> > >> * When a

Re: [PATCH v8 10/41] richacl: Permission check algorithm

gt; includes the requested permissions. > > Signed-off-by: Andreas Gruenbacher <agrue...@redhat.com> > Reviewed-by: "J. Bruce Fields" <bfie...@fieldses.org> > --- > fs/Makefile | 2 +- > fs/richacl_inode.c | 148 > ++

Re: [PATCH v8 10/41] richacl: Permission check algorithm

On Mon, Sep 28, 2015 at 06:25:23PM +0200, Andreas Grünbacher wrote: > 2015-09-28 18:08 GMT+02:00 J. Bruce Fields <bfie...@fieldses.org>: > > On Mon, Sep 28, 2015 at 12:09:01AM +0200, Andreas Gruenbacher wrote: > >> + /* > >> + * Check if the acl grants t

Re: [PATCH v8 09/41] richacl: Update the file masks in chmod()

n. > > Signed-off-by: Andreas Gruenbacher <agrue...@redhat.com> > Reviewed-by: J. Bruce Fields <bfie...@redhat.com> > --- > fs/richacl_base.c | 40 > include/linux/richacl.h | 1 + > 2 files changed, 41 insertions(+) >

Re: [PATCH 01/19] SUNRPC: fix variable type

ACK. Assuming Trond gets this.--b. On Thu, Sep 24, 2015 at 04:00:09PM +0200, Andrzej Hajda wrote: > Due to incorrect len type bc_send_request returned always zero. > > The problem has been detected using proposed semantic patch > scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1]. >

Re: [RFC v7 25/41] richacl: Isolate the owner and group classes

On Fri, Sep 25, 2015 at 01:25:41PM +0200, Andreas Gruenbacher wrote: > Here is another minor improvement that produces deny aces with fewer > permissions in them and avoids creating unnecessary deny aces in some > cases. Looks good.--b. > > Andreas > > --- > fs/richacl_compat.c | 5 ++--- > 1

Re: [PATCH] richacl: Possible other write-through fix

On Fri, Sep 25, 2015 at 06:45:59PM +0200, Andreas Gruenbacher wrote: > 2015-09-24 20:33 GMT+02:00 J. Bruce Fields : > > On Sat, Sep 05, 2015 at 12:27:21PM +0200, Andreas Gruenbacher wrote: > >> +int > >> +richacl_apply_masks(struct richacl **acl, kuid_t owner) &

Re: [RFC v7 25/41] richacl: Isolate the owner and group classes

On Fri, Sep 25, 2015 at 01:25:41PM +0200, Andreas Gruenbacher wrote: > Here is another minor improvement that produces deny aces with fewer > permissions in them and avoids creating unnecessary deny aces in some > cases. Looks good.--b. > > Andreas > > --- > fs/richacl_compat.c | 5 ++--- > 1

Re: [PATCH 01/19] SUNRPC: fix variable type

ACK. Assuming Trond gets this.--b. On Thu, Sep 24, 2015 at 04:00:09PM +0200, Andrzej Hajda wrote: > Due to incorrect len type bc_send_request returned always zero. > > The problem has been detected using proposed semantic patch > scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1]. >

Re: [PATCH] richacl: Possible other write-through fix

On Fri, Sep 25, 2015 at 06:45:59PM +0200, Andreas Gruenbacher wrote: > 2015-09-24 20:33 GMT+02:00 J. Bruce Fields <bfie...@fieldses.org>: > > On Sat, Sep 05, 2015 at 12:27:21PM +0200, Andreas Gruenbacher wrote: > >> +int > >> +richacl_apply_masks(s

Re: [RFC v7 32/41] nfsd: Add support for the MAY_CREATE_{FILE,DIR} permissions

On Sat, Sep 05, 2015 at 12:27:27PM +0200, Andreas Gruenbacher wrote: > For local file systems, the vfs performs the necessary permission checks > for operations like creating files and directories. NFSd duplicates > several of those checks. The vfs checks have been extended to check for >

Re: [RFC v7 31/41] nfsd: Add support for the v4.1 dacl attribute

On Sat, Sep 05, 2015 at 12:27:26PM +0200, Andreas Gruenbacher wrote: > Richacls support the Automatic Inheritance permission propagation > mechanism as specified in NFSv4.1. Over NFS, this requires support for > the dacl attribute: compared to the acl attribute, the dacl attribute > has an

Re: [RFC v7 30/41] nfsd: Add richacl support

On Sat, Sep 05, 2015 at 12:27:25PM +0200, Andreas Gruenbacher wrote: > On file systems with richacls enabled, get and set richacls directly > instead of converting from / to posix acls. ACK.--b. > > Signed-off-by: Andreas Gruenbacher > --- > fs/nfsd/acl.h | 3 +- > fs/nfsd/nfs4acl.c |

Re: [RFC v7 29/41] nfsd: Use richacls as internal acl representation

On Sat, Sep 05, 2015 at 12:27:24PM +0200, Andreas Gruenbacher wrote: > When converting from NFSv4 ACLs to POSIX ACLs, nfsd so far was using > struct nfs4_acl as its internal representation. This representation is a > subset of richacls, so get rid of struct nfs4_acl. Richacls even have a > more

Re: [RFC v7 26/41] richacl: Apply the file masks to a richacl

On Sat, Sep 05, 2015 at 12:27:21PM +0200, Andreas Gruenbacher wrote: > Put all the pieces of the acl transformation puzzle together for > computing a richacl which has the file masks "applied" so that the > standard nfsv4 access check algorithm can be used on the richacl. > > Signed-off-by:

Re: [RFC v7 26/41] richacl: Apply the file masks to a richacl

On Thu, Sep 24, 2015 at 12:14:40AM +0200, Andreas Gruenbacher wrote: > 2015-09-23 23:05 GMT+02:00 J. Bruce Fields : > > On Wed, Sep 23, 2015 at 10:40:18PM +0200, Andreas Gruenbacher wrote: > >> 2015-09-23 22:33 GMT+02:00 J. Bruce Fields : > >> > The same could be sa

Re: [RFC v7 26/41] richacl: Apply the file masks to a richacl

On Thu, Sep 24, 2015 at 12:14:40AM +0200, Andreas Gruenbacher wrote: > 2015-09-23 23:05 GMT+02:00 J. Bruce Fields <bfie...@fieldses.org>: > > On Wed, Sep 23, 2015 at 10:40:18PM +0200, Andreas Gruenbacher wrote: > >> 2015-09-23 22:33 GMT+02:00 J. Bruce Fields <bfie...@fie

Re: [RFC v7 26/41] richacl: Apply the file masks to a richacl

On Sat, Sep 05, 2015 at 12:27:21PM +0200, Andreas Gruenbacher wrote: > Put all the pieces of the acl transformation puzzle together for > computing a richacl which has the file masks "applied" so that the > standard nfsv4 access check algorithm can be used on the richacl. > > Signed-off-by:

Re: [RFC v7 29/41] nfsd: Use richacls as internal acl representation

On Sat, Sep 05, 2015 at 12:27:24PM +0200, Andreas Gruenbacher wrote: > When converting from NFSv4 ACLs to POSIX ACLs, nfsd so far was using > struct nfs4_acl as its internal representation. This representation is a > subset of richacls, so get rid of struct nfs4_acl. Richacls even have a > more

Re: [RFC v7 31/41] nfsd: Add support for the v4.1 dacl attribute

On Sat, Sep 05, 2015 at 12:27:26PM +0200, Andreas Gruenbacher wrote: > Richacls support the Automatic Inheritance permission propagation > mechanism as specified in NFSv4.1. Over NFS, this requires support for > the dacl attribute: compared to the acl attribute, the dacl attribute > has an

Re: [RFC v7 32/41] nfsd: Add support for the MAY_CREATE_{FILE,DIR} permissions

On Sat, Sep 05, 2015 at 12:27:27PM +0200, Andreas Gruenbacher wrote: > For local file systems, the vfs performs the necessary permission checks > for operations like creating files and directories. NFSd duplicates > several of those checks. The vfs checks have been extended to check for >

Re: [RFC v7 30/41] nfsd: Add richacl support

On Sat, Sep 05, 2015 at 12:27:25PM +0200, Andreas Gruenbacher wrote: > On file systems with richacls enabled, get and set richacls directly > instead of converting from / to posix acls. ACK.--b. > > Signed-off-by: Andreas Gruenbacher > --- > fs/nfsd/acl.h | 3 +- >

Re: [RFC v7 26/41] richacl: Apply the file masks to a richacl

On Wed, Sep 23, 2015 at 10:40:18PM +0200, Andreas Gruenbacher wrote: > 2015-09-23 22:33 GMT+02:00 J. Bruce Fields : > > The same could be said if there's a group-i-belong-to:rwx::allow entry, > > do we make that exception too? > > We cannot because that would be incorrec

Re: [RFC v7 26/41] richacl: Apply the file masks to a richacl

On Wed, Sep 23, 2015 at 10:29:40PM +0200, Andreas Gruenbacher wrote: > 2015-09-23 21:18 GMT+02:00 J. Bruce Fields : > > On Tue, Sep 22, 2015 at 03:11:08PM -0400, bfields wrote: > >> user aces like owner aces what you intended to do, > >> and if so, why? > &g

Re: [RFC v7 28/41] nfsd: Keep list of acls to dispose of in compoundargs

On Sat, Sep 05, 2015 at 12:27:23PM +0200, Andreas Gruenbacher wrote: > We will decode acls in requests into richacls. Even if unlikely, there > can be more than one acl in a single request; those richacls need to be > richacl_put() at the end of the request instead of kfree()d, so keep a > list

Re: [RFC v7 27/41] richacl: Create richacl from mode values

he NFSv4 protocol, a file always has an acl, and we convert the file > mode permission bits into an equivalent acl with richacl_from_mode. Such > "trivial" acls can be converted back to a file mode with > richacl_equiv_mode. Reviewed-by: J. Bruce Fields > > Signed-off-by:

Re: [RFC v7 26/41] richacl: Apply the file masks to a richacl

On Tue, Sep 22, 2015 at 03:11:08PM -0400, bfields wrote: > On Sat, Sep 05, 2015 at 12:27:21PM +0200, Andreas Gruenbacher wrote: > > Put all the pieces of the acl transformation puzzle together for > > computing a richacl which has the file masks "applied" so that the > > standard nfsv4 access

Re: [RFC v7 24/41] richacl: Set the other permissions to the other mask

On Sat, Sep 05, 2015 at 12:27:19PM +0200, Andreas Gruenbacher wrote: > Change the acl so that everyone@ is granted the permissions set in the > other mask. > > Signed-off-by: Andreas Gruenbacher > --- > fs/richacl_compat.c | 35 +++ > 1 file changed, 35

Re: [RFC v7 15/41] richacl: Automatic Inheritance

On Mon, Sep 21, 2015 at 09:51:46PM -0400, J. Bruce Fields wrote: > On Mon, Sep 21, 2015 at 11:19:59PM +0200, Andreas Gruenbacher wrote: > > 2015-09-18 20:40 GMT+02:00 J. Bruce Fields : > > > On Sat, Sep 05, 2015 at 12:27:10PM +0200, Andreas Gruenbacher wrote: > > >

Re: [RFC v7 25/41] richacl: Isolate the owner and group classes

On Wed, Sep 23, 2015 at 03:11:45PM +0200, Andreas Gruenbacher wrote: > 2015-09-22 18:06 GMT+02:00 J. Bruce Fields : > > On Sat, Sep 05, 2015 at 12:27:20PM +0200, Andreas Gruenbacher wrote: > >> When applying the file masks to an acl, we need to ensure that no > >> pr

Re: [RFC v7 25/41] richacl: Isolate the owner and group classes

On Wed, Sep 23, 2015 at 03:11:45PM +0200, Andreas Gruenbacher wrote: > 2015-09-22 18:06 GMT+02:00 J. Bruce Fields <bfie...@fieldses.org>: > > On Sat, Sep 05, 2015 at 12:27:20PM +0200, Andreas Gruenbacher wrote: > >> When applying the file masks to an acl, we need to ens

Re: [RFC v7 24/41] richacl: Set the other permissions to the other mask

On Sat, Sep 05, 2015 at 12:27:19PM +0200, Andreas Gruenbacher wrote: > Change the acl so that everyone@ is granted the permissions set in the > other mask. > > Signed-off-by: Andreas Gruenbacher > --- > fs/richacl_compat.c | 35 +++ > 1 file

Re: [RFC v7 15/41] richacl: Automatic Inheritance

On Mon, Sep 21, 2015 at 09:51:46PM -0400, J. Bruce Fields wrote: > On Mon, Sep 21, 2015 at 11:19:59PM +0200, Andreas Gruenbacher wrote: > > 2015-09-18 20:40 GMT+02:00 J. Bruce Fields <bfie...@fieldses.org>: > > > On Sat, Sep 05, 2015 at 12:27:10PM +0200, Andreas Gruenbacher

Re: [RFC v7 26/41] richacl: Apply the file masks to a richacl

On Tue, Sep 22, 2015 at 03:11:08PM -0400, bfields wrote: > On Sat, Sep 05, 2015 at 12:27:21PM +0200, Andreas Gruenbacher wrote: > > Put all the pieces of the acl transformation puzzle together for > > computing a richacl which has the file masks "applied" so that the > > standard nfsv4 access

Re: [RFC v7 26/41] richacl: Apply the file masks to a richacl

On Wed, Sep 23, 2015 at 10:29:40PM +0200, Andreas Gruenbacher wrote: > 2015-09-23 21:18 GMT+02:00 J. Bruce Fields <bfie...@fieldses.org>: > > On Tue, Sep 22, 2015 at 03:11:08PM -0400, bfields wrote: > >> user aces like owner aces what you intended to do, > >> and i

Re: [RFC v7 27/41] richacl: Create richacl from mode values

he NFSv4 protocol, a file always has an acl, and we convert the file > mode permission bits into an equivalent acl with richacl_from_mode. Such > "trivial" acls can be converted back to a file mode with > richacl_equiv_mode. Reviewed-by: J. Bruce Fields <bfie...@redhat.com&g

Re: [RFC v7 28/41] nfsd: Keep list of acls to dispose of in compoundargs

On Sat, Sep 05, 2015 at 12:27:23PM +0200, Andreas Gruenbacher wrote: > We will decode acls in requests into richacls. Even if unlikely, there > can be more than one acl in a single request; those richacls need to be > richacl_put() at the end of the request instead of kfree()d, so keep a > list

Re: [RFC v7 26/41] richacl: Apply the file masks to a richacl

On Wed, Sep 23, 2015 at 10:40:18PM +0200, Andreas Gruenbacher wrote: > 2015-09-23 22:33 GMT+02:00 J. Bruce Fields <bfie...@fieldses.org>: > > The same could be said if there's a group-i-belong-to:rwx::allow entry, > > do we make that exception too? > > We cannot beca

Re: [RFC v7 22/41] richacl: Propagate everyone@ permissions to other aces

On Wed, Sep 23, 2015 at 03:39:44AM +0200, Andreas Gruenbacher wrote: > Here are my improvements; hope that helps ... Yes, looks good, thanks!--b. > > Thanks, > Andreas > > diff --git a/fs/richacl_compat.c b/fs/richacl_compat.c > index 9b76fc0..21af9a0 100644 > --- a/fs/richacl_compat.c > +++

Re: [RFC v7 26/41] richacl: Apply the file masks to a richacl

On Sat, Sep 05, 2015 at 12:27:21PM +0200, Andreas Gruenbacher wrote: > Put all the pieces of the acl transformation puzzle together for > computing a richacl which has the file masks "applied" so that the > standard nfsv4 access check algorithm can be used on the richacl. > > Signed-off-by:

Re: [RFC v7 26/41] richacl: Apply the file masks to a richacl

On Sat, Sep 05, 2015 at 12:27:21PM +0200, Andreas Gruenbacher wrote: > Put all the pieces of the acl transformation puzzle together for > computing a richacl which has the file masks "applied" so that the > standard nfsv4 access check algorithm can be used on the richacl. > > Signed-off-by:

Re: [RFC v7 25/41] richacl: Isolate the owner and group classes

Oh, and my only comments were nits, this looks good to me: Reviewed-by: J. Bruce Fields --b. On Sat, Sep 05, 2015 at 12:27:20PM +0200, Andreas Gruenbacher wrote: > When applying the file masks to an acl, we need to ensure that no > process gets more permissions than allowed by it

Re: [RFC v7 25/41] richacl: Isolate the owner and group classes

On Sat, Sep 05, 2015 at 12:27:20PM +0200, Andreas Gruenbacher wrote: > When applying the file masks to an acl, we need to ensure that no > process gets more permissions than allowed by its file mask. > > This may require inserting an owner@ deny ace to ensure this if the > owner mask contains

Re: [RFC v7 25/41] richacl: Isolate the owner and group classes

On Sat, Sep 05, 2015 at 12:27:20PM +0200, Andreas Gruenbacher wrote: > When applying the file masks to an acl, we need to ensure that no > process gets more permissions than allowed by its file mask. > > This may require inserting an owner@ deny ace to ensure this if the > owner mask contains

Re: [RFC v7 25/41] richacl: Isolate the owner and group classes

On Sat, Sep 05, 2015 at 12:27:20PM +0200, Andreas Gruenbacher wrote: > When applying the file masks to an acl, we need to ensure that no > process gets more permissions than allowed by its file mask. > > This may require inserting an owner@ deny ace to ensure this if the > owner mask contains

Re: [RFC v7 25/41] richacl: Isolate the owner and group classes

Oh, and my only comments were nits, this looks good to me: Reviewed-by: J. Bruce Fields <bfie...@redhat.com> --b. On Sat, Sep 05, 2015 at 12:27:20PM +0200, Andreas Gruenbacher wrote: > When applying the file masks to an acl, we need to ensure that no > process gets more perm

Re: [RFC v7 26/41] richacl: Apply the file masks to a richacl

On Sat, Sep 05, 2015 at 12:27:21PM +0200, Andreas Gruenbacher wrote: > Put all the pieces of the acl transformation puzzle together for > computing a richacl which has the file masks "applied" so that the > standard nfsv4 access check algorithm can be used on the richacl. > > Signed-off-by:

Re: [RFC v7 25/41] richacl: Isolate the owner and group classes

On Sat, Sep 05, 2015 at 12:27:20PM +0200, Andreas Gruenbacher wrote: > When applying the file masks to an acl, we need to ensure that no > process gets more permissions than allowed by its file mask. > > This may require inserting an owner@ deny ace to ensure this if the > owner mask contains

Re: [RFC v7 26/41] richacl: Apply the file masks to a richacl

On Sat, Sep 05, 2015 at 12:27:21PM +0200, Andreas Gruenbacher wrote: > Put all the pieces of the acl transformation puzzle together for > computing a richacl which has the file masks "applied" so that the > standard nfsv4 access check algorithm can be used on the richacl. > > Signed-off-by:

Re: [RFC v7 22/41] richacl: Propagate everyone@ permissions to other aces

On Wed, Sep 23, 2015 at 03:39:44AM +0200, Andreas Gruenbacher wrote: > Here are my improvements; hope that helps ... Yes, looks good, thanks!--b. > > Thanks, > Andreas > > diff --git a/fs/richacl_compat.c b/fs/richacl_compat.c > index 9b76fc0..21af9a0 100644 > --- a/fs/richacl_compat.c > +++

Re: [RFC v7 21/41] richacl: Move everyone@ aces down the acl

On Mon, Sep 21, 2015 at 11:43:16PM +0200, Andreas Gruenbacher wrote: > 2015-09-18 21:35 GMT+02:00 J. Bruce Fields : > > On Sat, Sep 05, 2015 at 12:27:16PM +0200, Andreas Gruenbacher wrote: > >> The POSIX standard puts processes which are not the owner or a member in > >>

Re: [RFC v7 15/41] richacl: Automatic Inheritance

On Mon, Sep 21, 2015 at 11:19:59PM +0200, Andreas Gruenbacher wrote: > 2015-09-18 20:40 GMT+02:00 J. Bruce Fields : > > On Sat, Sep 05, 2015 at 12:27:10PM +0200, Andreas Gruenbacher wrote: > >> Automatic Inheritance (AI) allows changes to the acl of a directory to > > In th

Re: [RFC v7 23/41] richacl: Set the owner permissions to the owner mask

& WRITE_THROUGH case modification of OWNER@ aces doesn't affect permissions.) Anyway, code looks right to me: Reviewed-by: J. Bruce Fields --b. > + */ > +static int > +richacl_set_owner_permissions(struct richacl_alloc *alloc) > +{ > + unsigned int x = RICHACE_POSIX_ALW

Re: [RFC v7 22/41] richacl: Propagate everyone@ permissions to other aces

On Fri, Sep 18, 2015 at 05:56:11PM -0400, bfields wrote: > On Sat, Sep 05, 2015 at 12:27:17PM +0200, Andreas Gruenbacher wrote: > > The trailing everyone@ allow ace can grant permissions to all file > > classes including the owner and group class. Before we can apply the > > other mask to this

Re: [RFC v7 13/41] richacl: Check if an acl is equivalent to a file mode

On Mon, Sep 21, 2015 at 01:00:40PM -0400, Austin S Hemmelgarn wrote: > On 2015-09-21 10:38, J. Bruce Fields wrote: > >On Mon, Sep 21, 2015 at 09:59:07AM -0400, Austin S Hemmelgarn wrote: > >>On 2015-09-17 20:56, J. Bruce Fields wrote: > >>>On Thu, Sep 17, 2015 at 0

Re: [RFC v7 13/41] richacl: Check if an acl is equivalent to a file mode

k the choices you've made probably make the most sense, they just > >wouldn't have been obvious to me. Anyway, so, OK by me: > > > > Reviewed-by: J. Bruce Fields > > > >--b. > > > >> > >>--b. >

Re: [RFC v7 13/41] richacl: Check if an acl is equivalent to a file mode

On Mon, Sep 21, 2015 at 09:59:07AM -0400, Austin S Hemmelgarn wrote: > On 2015-09-17 20:56, J. Bruce Fields wrote: > >On Thu, Sep 17, 2015 at 02:22:19PM -0400, bfields wrote: > >>On Sat, Sep 05, 2015 at 12:27:08PM +0200, Andreas Gruenbacher wrote: > >>>ACLs are consi

Re: [RFC v7 21/41] richacl: Move everyone@ aces down the acl

On Mon, Sep 21, 2015 at 11:43:16PM +0200, Andreas Gruenbacher wrote: > 2015-09-18 21:35 GMT+02:00 J. Bruce Fields <bfie...@fieldses.org>: > > On Sat, Sep 05, 2015 at 12:27:16PM +0200, Andreas Gruenbacher wrote: > >> The POSIX standard puts processes which are n

Re: [RFC v7 15/41] richacl: Automatic Inheritance

On Mon, Sep 21, 2015 at 11:19:59PM +0200, Andreas Gruenbacher wrote: > 2015-09-18 20:40 GMT+02:00 J. Bruce Fields <bfie...@fieldses.org>: > > On Sat, Sep 05, 2015 at 12:27:10PM +0200, Andreas Gruenbacher wrote: > >> Automatic Inheritance (AI) allows changes t

Re: [RFC v7 13/41] richacl: Check if an acl is equivalent to a file mode

k the choices you've made probably make the most sense, they just > >wouldn't have been obvious to me. Anyway, so, OK by me: > > > > Reviewed-by: J. Bruce Fields <bfie...@redhat.com> > > > >--b. > > > >> > >>--b. > >> >

Re: [RFC v7 13/41] richacl: Check if an acl is equivalent to a file mode

On Mon, Sep 21, 2015 at 01:00:40PM -0400, Austin S Hemmelgarn wrote: > On 2015-09-21 10:38, J. Bruce Fields wrote: > >On Mon, Sep 21, 2015 at 09:59:07AM -0400, Austin S Hemmelgarn wrote: > >>On 2015-09-17 20:56, J. Bruce Fields wrote: > >>>On Thu, Sep 17, 2015 at 0

Re: [RFC v7 13/41] richacl: Check if an acl is equivalent to a file mode

On Mon, Sep 21, 2015 at 09:59:07AM -0400, Austin S Hemmelgarn wrote: > On 2015-09-17 20:56, J. Bruce Fields wrote: > >On Thu, Sep 17, 2015 at 02:22:19PM -0400, bfields wrote: > >>On Sat, Sep 05, 2015 at 12:27:08PM +0200, Andreas Gruenbacher wrote: > >>>ACLs are consi

Re: [RFC v7 22/41] richacl: Propagate everyone@ permissions to other aces

On Fri, Sep 18, 2015 at 05:56:11PM -0400, bfields wrote: > On Sat, Sep 05, 2015 at 12:27:17PM +0200, Andreas Gruenbacher wrote: > > The trailing everyone@ allow ace can grant permissions to all file > > classes including the owner and group class. Before we can apply the > > other mask to this

Re: [RFC v7 23/41] richacl: Set the owner permissions to the owner mask

aces, and in the MASKED & WRITE_THROUGH case modification of OWNER@ aces doesn't affect permissions.) Anyway, code looks right to me: Reviewed-by: J. Bruce Fields <bfie...@redhat.com> --b. > + */ > +static int > +richacl_set_owner_permissions(struct richacl_alloc *alloc)

Re: [RFC v7 22/41] richacl: Propagate everyone@ permissions to other aces

On Sat, Sep 05, 2015 at 12:27:17PM +0200, Andreas Gruenbacher wrote: > The trailing everyone@ allow ace can grant permissions to all file > classes including the owner and group class. Before we can apply the > other mask to this entry to turn it into an "other class" entry, we need > to ensure

Re: [RFC v7 22/41] richacl: Propagate everyone@ permissions to other aces

On Sat, Sep 05, 2015 at 12:27:17PM +0200, Andreas Gruenbacher wrote: > The trailing everyone@ allow ace can grant permissions to all file > classes including the owner and group class. Before we can apply the > other mask to this entry to turn it into an "other class" entry, we need > to ensure

Re: [RFC v7 21/41] richacl: Move everyone@ aces down the acl

t_ace) && > + richace_is_inherit_only(last_ace) && > + last_ace->e_mask == allowed) > + last_ace->e_flags &= ~RICHACE_INHERIT_ONLY_ACE; That's a funny special case! Is it even worth it, or

Re: [RFC v7 20/41] richacl: acl editing helper functions

so that it can be > evaluated as a plain nfs4 acl, with identical permission check results. Reviewed-by: J. Bruce Fields Looks nicely done.--b. > > Signed-off-by: Andreas Gruenbacher > --- > fs/Makefile| 3 +- > fs/richacl_compat.c| 155 > +

Re: [RFC v7 15/41] richacl: Automatic Inheritance

On Sat, Sep 05, 2015 at 12:27:10PM +0200, Andreas Gruenbacher wrote: > Automatic Inheritance (AI) allows changes to the acl of a directory to > propagate down to children. > > This is mostly implemented in user space: when a process changes the > permissions of a directory and Automatic

Re: [RFC v7 14/41] richacl: Create-time inheritance

> + mask = inode->i_mode; > + if (richacl_equiv_mode(acl, ) == 0) { > + richacl_put(acl); > + acl = NULL; Why is it correct to ignore entirely the inherited acl in this case? Oh, I see, I'm forgetting that richacl_equiv

Re: [RFC v7 20/41] richacl: acl editing helper functions

so that it can be > evaluated as a plain nfs4 acl, with identical permission check results. Reviewed-by: J. Bruce Fields <bfie...@redhat.com> Looks nicely done.--b. > > Signed-off-by: Andreas Gruenbacher <agr...@kernel.org> > --- > fs/

Re: [RFC v7 21/41] richacl: Move everyone@ aces down the acl

ichace_is_allow(last_ace) && > + richace_is_inherit_only(last_ace) && > + last_ace->e_mask == allowed) > + last_ace->e_flags &= ~RICHACE_INHERIT_ONLY_ACE; That's a f

Re: [RFC v7 15/41] richacl: Automatic Inheritance

On Sat, Sep 05, 2015 at 12:27:10PM +0200, Andreas Gruenbacher wrote: > Automatic Inheritance (AI) allows changes to the acl of a directory to > propagate down to children. > > This is mostly implemented in user space: when a process changes the > permissions of a directory and Automatic

Re: [RFC v7 14/41] richacl: Create-time inheritance

); > + if (acl) { > + mask = inode->i_mode; > + if (richacl_equiv_mode(acl, ) == 0) { > + richacl_put(acl); > + acl = NULL; Why is it correct to ignore entirely the inherited acl in this case? Oh, I see, I'

<    4   5   6   7   8   9   10   11   12   13   >