Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Thu, Mar 30, 2017 at 10:41:37AM +1100, Dave Chinner wrote: > On Wed, Mar 29, 2017 at 01:54:31PM -0400, Jeff Layton wrote: > > On Wed, 2017-03-29 at 13:15 +0200, Jan Kara wrote: > > > On Tue 21-03-17 14:46:53, Jeff Layton wrote: > > > > On Tue, 2017-03-21 at 14:3

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Thu, Mar 30, 2017 at 10:41:37AM +1100, Dave Chinner wrote: > On Wed, Mar 29, 2017 at 01:54:31PM -0400, Jeff Layton wrote: > > On Wed, 2017-03-29 at 13:15 +0200, Jan Kara wrote: > > > On Tue 21-03-17 14:46:53, Jeff Layton wrote: > > > > On Tue, 2017-03-21 at 14:3

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Thu, Mar 30, 2017 at 02:35:32PM -0400, Jeff Layton wrote: > On Thu, 2017-03-30 at 12:12 -0400, J. Bruce Fields wrote: > > On Thu, Mar 30, 2017 at 07:11:48AM -0400, Jeff Layton wrote: > > > On Thu, 2017-03-30 at 08:47 +0200, Jan Kara wrote: > > > > Because if abo

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Thu, Mar 30, 2017 at 02:35:32PM -0400, Jeff Layton wrote: > On Thu, 2017-03-30 at 12:12 -0400, J. Bruce Fields wrote: > > On Thu, Mar 30, 2017 at 07:11:48AM -0400, Jeff Layton wrote: > > > On Thu, 2017-03-30 at 08:47 +0200, Jan Kara wrote: > > > > Because if abo

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Tue, Apr 04, 2017 at 10:34:14PM +1000, Dave Chinner wrote: > On Mon, Apr 03, 2017 at 04:00:55PM +0200, Jan Kara wrote: > > What filesystems can or cannot easily do obviously differs. Ext4 has a > > recovery flag set in superblock on RW mount/remount and cleared on > > umount/RO remount. > >

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Tue, Apr 04, 2017 at 10:34:14PM +1000, Dave Chinner wrote: > On Mon, Apr 03, 2017 at 04:00:55PM +0200, Jan Kara wrote: > > What filesystems can or cannot easily do obviously differs. Ext4 has a > > recovery flag set in superblock on RW mount/remount and cleared on > > umount/RO remount. > >

Re: linux-next: build warning after merge of the nfsd tree

On Mon, Apr 03, 2017 at 11:09:48AM +1000, Stephen Rothwell wrote: > Hi, > > After merging the nfsd tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > fs/nfsd/nfs4state.c: In function 'copy_cred': > fs/nfsd/nfs4state.c:1917:6: warning: unused variable 'ret'

Re: linux-next: build warning after merge of the nfsd tree

On Mon, Apr 03, 2017 at 11:09:48AM +1000, Stephen Rothwell wrote: > Hi, > > After merging the nfsd tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > fs/nfsd/nfs4state.c: In function 'copy_cred': > fs/nfsd/nfs4state.c:1917:6: warning: unused variable 'ret'

[GIT PULL] nfsd bugfixes for 4.11

Please pull nfsd bugfixes from git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.11-1 The restriction of NFSv4 to TCP went overboard and also broke the backchannel; fix. Also some minor refinements to the nfsd version-setting interface that we'd like to get fixed before release. --b. Chuck

[GIT PULL] nfsd bugfixes for 4.11

Please pull nfsd bugfixes from git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.11-1 The restriction of NFSv4 to TCP went overboard and also broke the backchannel; fix. Also some minor refinements to the nfsd version-setting interface that we'd like to get fixed before release. --b. Chuck

Re: [PATCH] selinux: Fix SBLABEL_MNT for NFS mounts

On Thu, Mar 30, 2017 at 01:27:07PM -0400, Stephen Smalley wrote: > On Thu, 2017-03-30 at 09:49 +0200, Tomeu Vizoso wrote: > > On 29 March 2017 at 23:34, J. Bruce Fields <bfie...@redhat.com> > > wrote: > > > On Wed, Mar 29, 2017 at 05:27:23PM +0200, Tomeu Vizoso wro

Re: [PATCH] selinux: Fix SBLABEL_MNT for NFS mounts

On Thu, Mar 30, 2017 at 01:27:07PM -0400, Stephen Smalley wrote: > On Thu, 2017-03-30 at 09:49 +0200, Tomeu Vizoso wrote: > > On 29 March 2017 at 23:34, J. Bruce Fields > > wrote: > > > On Wed, Mar 29, 2017 at 05:27:23PM +0200, Tomeu Vizoso wrote: > > > > Label

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Thu, Mar 30, 2017 at 07:11:48AM -0400, Jeff Layton wrote: > On Thu, 2017-03-30 at 08:47 +0200, Jan Kara wrote: > > Hum, so are we fine if i_version just changes (increases) for all inodes > > after a server crash? If I understand its use right, it would mean > > invalidation of all client's

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Thu, Mar 30, 2017 at 07:11:48AM -0400, Jeff Layton wrote: > On Thu, 2017-03-30 at 08:47 +0200, Jan Kara wrote: > > Hum, so are we fine if i_version just changes (increases) for all inodes > > after a server crash? If I understand its use right, it would mean > > invalidation of all client's

Re: [PATCH] fs: drop duplicate header percpu-rwsem.h

Fine by me, but I'm not sure why you're sending it to us. Looks at MAINTAINERS Oh, I see, include/linux/fs.h is under "FILE LOCKING". Hm. Anyway, this one's probably for Al Viro. --b. On Fri, Mar 24, 2017 at 10:13:36PM +0800, Geliang Tang wrote: > Drop duplicate header percpu-rwsem.h

Re: [PATCH] fs: drop duplicate header percpu-rwsem.h

Fine by me, but I'm not sure why you're sending it to us. Looks at MAINTAINERS Oh, I see, include/linux/fs.h is under "FILE LOCKING". Hm. Anyway, this one's probably for Al Viro. --b. On Fri, Mar 24, 2017 at 10:13:36PM +0800, Geliang Tang wrote: > Drop duplicate header percpu-rwsem.h

Re: [PATCH] selinux: Fix SBLABEL_MNT for NFS mounts

-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com> > Cc: J. Bruce Fields <bfie...@redhat.com> > > --- > > Hi, > > cannot remotely say that I currently understand how selinux is expected > to work within NFS mounts, but this change allowed me to fully boot AOSP > wi

Re: [PATCH] selinux: Fix SBLABEL_MNT for NFS mounts

y: Tomeu Vizoso > Cc: J. Bruce Fields > > --- > > Hi, > > cannot remotely say that I currently understand how selinux is expected > to work within NFS mounts, but this change allowed me to fully boot AOSP > with its rootfs and ramdisk on a single NFS share. > >

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Tue, Mar 21, 2017 at 02:46:53PM -0400, Jeff Layton wrote: > On Tue, 2017-03-21 at 14:30 -0400, J. Bruce Fields wrote: > > On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote: > > > On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote: > > > > - It's

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Tue, Mar 21, 2017 at 02:46:53PM -0400, Jeff Layton wrote: > On Tue, 2017-03-21 at 14:30 -0400, J. Bruce Fields wrote: > > On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote: > > > On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote: > > > > - It's

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote: > On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote: > > - It's durable; the above comparison still works if there were reboots > > between the two i_version checks. > > - I don't know how realistic

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote: > On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote: > > - It's durable; the above comparison still works if there were reboots > > between the two i_version checks. > > - I don't know how realistic

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Tue, Mar 21, 2017 at 01:37:04PM -0400, J. Bruce Fields wrote: > On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote: > > On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote: > > > - NFS doesn't actually require that it increases, but I think it > > >

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Tue, Mar 21, 2017 at 01:37:04PM -0400, J. Bruce Fields wrote: > On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote: > > On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote: > > > - NFS doesn't actually require that it increases, but I think it > > >

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Tue, Mar 21, 2017 at 05:41:22PM +0100, Jan Kara wrote: > On Tue 21-03-17 11:38:49, J. Bruce Fields wrote: > > On Sun, Mar 19, 2017 at 11:19:43AM +0100, Jan Kara wrote: > > > On Tue 14-03-17 13:18:01, Amir Goldstein wrote: > > > > On Tue, Mar 14, 2017 at

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Tue, Mar 21, 2017 at 05:41:22PM +0100, Jan Kara wrote: > On Tue 21-03-17 11:38:49, J. Bruce Fields wrote: > > On Sun, Mar 19, 2017 at 11:19:43AM +0100, Jan Kara wrote: > > > On Tue 14-03-17 13:18:01, Amir Goldstein wrote: > > > > On Tue, Mar 14, 2017 at 1:03 AM, Fi

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote: > On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote: > > - NFS doesn't actually require that it increases, but I think it > > should. I assume 64 bits means we don't need a discussion of > >

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote: > On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote: > > - NFS doesn't actually require that it increases, but I think it > > should. I assume 64 bits means we don't need a discussion of > >

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Tue, Mar 21, 2017 at 06:45:00AM -0700, Christoph Hellwig wrote: > On Mon, Mar 20, 2017 at 05:43:27PM -0400, J. Bruce Fields wrote: > > To me, the interesting question is whether this allows us to turn on > > i_version updates by default on xfs and ext4. > > XFS

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Tue, Mar 21, 2017 at 06:45:00AM -0700, Christoph Hellwig wrote: > On Mon, Mar 20, 2017 at 05:43:27PM -0400, J. Bruce Fields wrote: > > To me, the interesting question is whether this allows us to turn on > > i_version updates by default on xfs and ext4. > > XFS

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Sun, Mar 19, 2017 at 11:19:43AM +0100, Jan Kara wrote: > On Tue 14-03-17 13:18:01, Amir Goldstein wrote: > > On Tue, Mar 14, 2017 at 1:03 AM, Filip Štědronský wrote: > > > Besause fanotify requires `struct path`, the event cannot be generated > > > directly in

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Sun, Mar 19, 2017 at 11:19:43AM +0100, Jan Kara wrote: > On Tue 14-03-17 13:18:01, Amir Goldstein wrote: > > On Tue, Mar 14, 2017 at 1:03 AM, Filip Štědronský wrote: > > > Besause fanotify requires `struct path`, the event cannot be generated > > > directly in `fsnotify_move` and friends

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Thu, Dec 22, 2016 at 09:42:04AM -0500, Jeff Layton wrote: > On Thu, 2016-12-22 at 00:45 -0800, Christoph Hellwig wrote: > > On Wed, Dec 21, 2016 at 12:03:17PM -0500, Jeff Layton wrote: > > > > > > Only btrfs, ext4, and xfs implement it for data changes. Because of > > > this, these filesystems

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Thu, Dec 22, 2016 at 09:42:04AM -0500, Jeff Layton wrote: > On Thu, 2016-12-22 at 00:45 -0800, Christoph Hellwig wrote: > > On Wed, Dec 21, 2016 at 12:03:17PM -0500, Jeff Layton wrote: > > > > > > Only btrfs, ext4, and xfs implement it for data changes. Because of > > > this, these filesystems

Re: [PATCH] uapi: fix linux/nfsd/cld.h userspace compilation errors

On Fri, Mar 10, 2017 at 01:31:14AM +0300, Dmitry V. Levin wrote: > On Thu, Mar 09, 2017 at 04:00:51PM -0500, J. Bruce Fields wrote: > > Why aren't the unitX_t types OK here? > > unitX_t types are not OK here because no UAPI header defines them, > include/uapi/linux/types.h defin

Re: [PATCH] uapi: fix linux/nfsd/cld.h userspace compilation errors

On Fri, Mar 10, 2017 at 01:31:14AM +0300, Dmitry V. Levin wrote: > On Thu, Mar 09, 2017 at 04:00:51PM -0500, J. Bruce Fields wrote: > > Why aren't the unitX_t types OK here? > > unitX_t types are not OK here because no UAPI header defines them, > include/uapi/linux/types.h defin

Re: [PATCH] uapi: fix linux/nfsd/cld.h userspace compilation errors

Why aren't the unitX_t types OK here? Anyway, assuming this is right I'll apply for 4.12. (I'm assuming it's not urgent since this file's always been this way.) --b. On Wed, Mar 01, 2017 at 03:12:03AM +0300, Dmitry V. Levin wrote: > Include and consistently use types it provides > to fix the

Re: [PATCH] uapi: fix linux/nfsd/cld.h userspace compilation errors

Why aren't the unitX_t types OK here? Anyway, assuming this is right I'll apply for 4.12. (I'm assuming it's not urgent since this file's always been this way.) --b. On Wed, Mar 01, 2017 at 03:12:03AM +0300, Dmitry V. Levin wrote: > Include and consistently use types it provides > to fix the

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Fri, Mar 03, 2017 at 07:53:57PM -0500, Jeff Layton wrote: > On Fri, 2017-03-03 at 18:00 -0500, J. Bruce Fields wrote: > > On Wed, Dec 21, 2016 at 12:03:17PM -0500, Jeff Layton wrote: > > > tl;dr: I think we can greatly reduce the cost of the inode->i_version > &g

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Fri, Mar 03, 2017 at 07:53:57PM -0500, Jeff Layton wrote: > On Fri, 2017-03-03 at 18:00 -0500, J. Bruce Fields wrote: > > On Wed, Dec 21, 2016 at 12:03:17PM -0500, Jeff Layton wrote: > > > tl;dr: I think we can greatly reduce the cost of the inode->i_version > &g

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Wed, Dec 21, 2016 at 12:03:17PM -0500, Jeff Layton wrote: > tl;dr: I think we can greatly reduce the cost of the inode->i_version > counter, by exploiting the fact that we don't need to increment it > if no one is looking at it. We can also clean up the code to prepare > to eventually expose

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Wed, Dec 21, 2016 at 12:03:17PM -0500, Jeff Layton wrote: > tl;dr: I think we can greatly reduce the cost of the inode->i_version > counter, by exploiting the fact that we don't need to increment it > if no one is looking at it. We can also clean up the code to prepare > to eventually expose

Re: [RFC PATCH v1 11/30] fs: new API for handling i_version

The patch ordering is a little annoying as I'd like to be able to be able to verify the implementation at the same time these new interfaces are added, but, I don't know, I don't have a better idea. Anyway, various nits: On Wed, Dec 21, 2016 at 12:03:28PM -0500, Jeff Layton wrote: > We already

Re: [RFC PATCH v1 11/30] fs: new API for handling i_version

The patch ordering is a little annoying as I'd like to be able to be able to verify the implementation at the same time these new interfaces are added, but, I don't know, I don't have a better idea. Anyway, various nits: On Wed, Dec 21, 2016 at 12:03:28PM -0500, Jeff Layton wrote: > We already

[GIT PULL] nfsd changes for 4.11

Call header decoder svcrdma: Clean up backchannel send header encoding svcrdma: Remove unused sc_dto_q field svcrdma: Combine list fields in struct svc_rdma_op_ctxt svcrdma: Poll CQs in "workqueue" mode J. Bruce Fields (3): nfsd: constify nfsd_suppatttrs

[GIT PULL] nfsd changes for 4.11

Call header decoder svcrdma: Clean up backchannel send header encoding svcrdma: Remove unused sc_dto_q field svcrdma: Combine list fields in struct svc_rdma_op_ctxt svcrdma: Poll CQs in "workqueue" mode J. Bruce Fields (3): nfsd: constify nfsd_suppatttrs

Re: [PATCH] fs: nfsd: remove superfluous KERN_INFO

Thanks, applying.--b. On Fri, Feb 24, 2017 at 01:15:55AM +0100, Rasmus Villemoes wrote: > dprintk already provides a KERN_* prefix; this KERN_INFO just shows up > as some odd characters in the output. > > Signed-off-by: Rasmus Villemoes > --- > fs/nfsd/nfs4state.c | 2

Re: [PATCH] fs: nfsd: remove superfluous KERN_INFO

Thanks, applying.--b. On Fri, Feb 24, 2017 at 01:15:55AM +0100, Rasmus Villemoes wrote: > dprintk already provides a KERN_* prefix; this KERN_INFO just shows up > as some odd characters in the output. > > Signed-off-by: Rasmus Villemoes > --- > fs/nfsd/nfs4state.c | 2 +- > 1 file changed, 1

[GIT PULL] nfsd bugfix for 4.10

been there, so we can wait another week or two to get this right. J. Bruce Fields (1): nfsd: Revert "nfsd: special case truncates some more" fs/nfsd/vfs.c | 97 -

[GIT PULL] nfsd bugfix for 4.10

been there, so we can wait another week or two to get this right. J. Bruce Fields (1): nfsd: Revert "nfsd: special case truncates some more" fs/nfsd/vfs.c | 97 -

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Mon, Feb 06, 2017 at 04:10:11PM -0800, James Bottomley wrote: > On Mon, 2017-02-06 at 16:52 -0500, J. Bruce Fields wrote: > > On Mon, Feb 06, 2017 at 07:18:16AM -0800, James Bottomley wrote: > > > On Mon, 2017-02-06 at 09:50 -0500, Theodore Ts'o wrote: > > > > On S

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Mon, Feb 06, 2017 at 04:10:11PM -0800, James Bottomley wrote: > On Mon, 2017-02-06 at 16:52 -0500, J. Bruce Fields wrote: > > On Mon, Feb 06, 2017 at 07:18:16AM -0800, James Bottomley wrote: > > > On Mon, 2017-02-06 at 09:50 -0500, Theodore Ts'o wrote: > > > > On S

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Mon, Feb 06, 2017 at 07:18:16AM -0800, James Bottomley wrote: > On Mon, 2017-02-06 at 09:50 -0500, Theodore Ts'o wrote: > > On Sun, Feb 05, 2017 at 10:46:23PM -0800, James Bottomley wrote: > > > Yes, I know the problem. However, I believe most current linux > > > filesystems no longer

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Mon, Feb 06, 2017 at 07:18:16AM -0800, James Bottomley wrote: > On Mon, 2017-02-06 at 09:50 -0500, Theodore Ts'o wrote: > > On Sun, Feb 05, 2017 at 10:46:23PM -0800, James Bottomley wrote: > > > Yes, I know the problem. However, I believe most current linux > > > filesystems no longer

[GIT PULL] second nfsd bugfix pull request

truncates some more J. Bruce Fields (1): svcrpc: fix oops in absence of krb5 module Kinglong Mee (1): NFSD: Fix a null reference case in find_or_create_lock_stateid() fs/nfsd/nfs4layouts.c | 5 +- fs/nfsd/nfs4state.c | 19 fs/nfsd/state.h

[GIT PULL] second nfsd bugfix pull request

truncates some more J. Bruce Fields (1): svcrpc: fix oops in absence of krb5 module Kinglong Mee (1): NFSD: Fix a null reference case in find_or_create_lock_stateid() fs/nfsd/nfs4layouts.c | 5 +- fs/nfsd/nfs4state.c | 19 fs/nfsd/state.h

Re: [kernel-hardening] Re: [PATCH 2/3] Make static usermode helper binaries constant

On Thu, Jan 19, 2017 at 01:03:21PM +0100, Greg KH wrote: > On Tue, Jan 17, 2017 at 04:29:19PM +0100, Greg KH wrote: > > On Tue, Jan 17, 2017 at 10:19:11AM -0500, J. Bruce Fields wrote: > > > On Tue, Jan 17, 2017 at 08:13:47AM +0100, Greg KH wrote: > > > > On Mon, Ja

Re: [kernel-hardening] Re: [PATCH 2/3] Make static usermode helper binaries constant

On Thu, Jan 19, 2017 at 01:03:21PM +0100, Greg KH wrote: > On Tue, Jan 17, 2017 at 04:29:19PM +0100, Greg KH wrote: > > On Tue, Jan 17, 2017 at 10:19:11AM -0500, J. Bruce Fields wrote: > > > On Tue, Jan 17, 2017 at 08:13:47AM +0100, Greg KH wrote: > > > > On Mon, Ja

Re: [PATCH 2/3] Make static usermode helper binaries constant

On Tue, Jan 17, 2017 at 08:13:47AM +0100, Greg KH wrote: > On Mon, Jan 16, 2017 at 04:25:55PM -0500, J. Bruce Fields wrote: > > On Mon, Jan 16, 2017 at 05:50:31PM +0100, Greg KH wrote: > > > From: Greg Kroah-Hartman <gre...@linuxfoundation.org> > > > > >

Re: [PATCH 2/3] Make static usermode helper binaries constant

On Tue, Jan 17, 2017 at 08:13:47AM +0100, Greg KH wrote: > On Mon, Jan 16, 2017 at 04:25:55PM -0500, J. Bruce Fields wrote: > > On Mon, Jan 16, 2017 at 05:50:31PM +0100, Greg KH wrote: > > > From: Greg Kroah-Hartman > > > > > > There are a number of usermode

Re: [PATCH 2/3] Make static usermode helper binaries constant

On Mon, Jan 16, 2017 at 05:50:31PM +0100, Greg KH wrote: > From: Greg Kroah-Hartman > > There are a number of usermode helper binaries that are "hard coded" in > the kernel today, so mark them as "const" to make it harder for someone > to change where the variables

Re: [PATCH 2/3] Make static usermode helper binaries constant

On Mon, Jan 16, 2017 at 05:50:31PM +0100, Greg KH wrote: > From: Greg Kroah-Hartman > > There are a number of usermode helper binaries that are "hard coded" in > the kernel today, so mark them as "const" to make it harder for someone > to change where the variables point to. > ... > ---

Re: [PATCH 3/6 linux-next] fs/affs: make affs exportable

On Fri, Jan 13, 2017 at 07:57:06PM +, Al Viro wrote: > On Fri, Jan 13, 2017 at 02:03:57PM -0500, J. Bruce Fields wrote: > > On Fri, Jan 13, 2017 at 10:52:54AM -0800, Christoph Hellwig wrote: > > > On Fri, Jan 13, 2017 at 12:39:12PM -0500, J. Bruce Fields wrote: > > >

Re: [PATCH 3/6 linux-next] fs/affs: make affs exportable

On Fri, Jan 13, 2017 at 07:57:06PM +, Al Viro wrote: > On Fri, Jan 13, 2017 at 02:03:57PM -0500, J. Bruce Fields wrote: > > On Fri, Jan 13, 2017 at 10:52:54AM -0800, Christoph Hellwig wrote: > > > On Fri, Jan 13, 2017 at 12:39:12PM -0500, J. Bruce Fields wrote: > > >

Re: [PATCH 3/6 linux-next] fs/affs: make affs exportable

On Fri, Jan 13, 2017 at 10:52:54AM -0800, Christoph Hellwig wrote: > On Fri, Jan 13, 2017 at 12:39:12PM -0500, J. Bruce Fields wrote: > > If we're going to reject patches that don't implement get_parent (and I > > think we should), then we should replace "optional but stro

Re: [PATCH 3/6 linux-next] fs/affs: make affs exportable

On Fri, Jan 13, 2017 at 10:52:54AM -0800, Christoph Hellwig wrote: > On Fri, Jan 13, 2017 at 12:39:12PM -0500, J. Bruce Fields wrote: > > If we're going to reject patches that don't implement get_parent (and I > > think we should), then we should replace "optional but stro

Re: [PATCH 3/6 linux-next] fs/affs: make affs exportable

On Wed, Jan 04, 2017 at 06:53:31AM +0100, Fabian Frederick wrote: > > > > On 03 January 2017 at 23:29 Al Viro wrote: > > > > > > On Tue, Jan 03, 2017 at 10:30:39PM +0100, Fabian Frederick wrote: > > > Add standard functions making AFFS work with NFS. > > > > > >

Re: [PATCH 3/6 linux-next] fs/affs: make affs exportable

On Wed, Jan 04, 2017 at 06:53:31AM +0100, Fabian Frederick wrote: > > > > On 03 January 2017 at 23:29 Al Viro wrote: > > > > > > On Tue, Jan 03, 2017 at 10:30:39PM +0100, Fabian Frederick wrote: > > > Add standard functions making AFFS work with NFS. > > > > > > Functions based on ext4

Re: [PATCH v5 1/2] sysctl: introduce new proc handler proc_dobool

On Thu, Dec 15, 2016 at 03:24:20PM +0800, Jia He wrote: > This is to let bool variable could be correctly displayed in > big/little endian sysctl procfs. sizeof(bool) is arch dependent, > proc_dobool should work in all arches. Did Alexey Debriyan agree that this dealt with his objections? Also

Re: [PATCH v5 1/2] sysctl: introduce new proc handler proc_dobool

On Thu, Dec 15, 2016 at 03:24:20PM +0800, Jia He wrote: > This is to let bool variable could be correctly displayed in > big/little endian sysctl procfs. sizeof(bool) is arch dependent, > proc_dobool should work in all arches. Did Alexey Debriyan agree that this dealt with his objections? Also

Re: NFS: SECINFO: security flavor 390003 is not supported

On Wed, Jan 04, 2017 at 02:29:01PM -0500, Dave Jones wrote: > On Wed, Jan 04, 2017 at 02:23:58PM -0500, Steve Dickson wrote: > > > > > > On 01/04/2017 02:03 PM, Dave Jones wrote: > > > Since upgrading to 4.10-rc2, my nfs server has started printing these.. > > > > > > [ 161.668635] NFS:

Re: NFS: SECINFO: security flavor 390003 is not supported

On Wed, Jan 04, 2017 at 02:29:01PM -0500, Dave Jones wrote: > On Wed, Jan 04, 2017 at 02:23:58PM -0500, Steve Dickson wrote: > > > > > > On 01/04/2017 02:03 PM, Dave Jones wrote: > > > Since upgrading to 4.10-rc2, my nfs server has started printing these.. > > > > > > [ 161.668635] NFS:

Re: [PATCH 3/6] ubifs: Use 64bit readdir cookies

On Thu, Dec 29, 2016 at 06:05:54PM +0100, Richard Weinberger wrote: > On 29.12.2016 17:59, J. Bruce Fields wrote: > > OK, good. So the random nonce is stored with the entry, and the hash > > you can always recalculate from the filename, so if you return entries > > in nonce

Re: [PATCH 3/6] ubifs: Use 64bit readdir cookies

On Thu, Dec 29, 2016 at 06:05:54PM +0100, Richard Weinberger wrote: > On 29.12.2016 17:59, J. Bruce Fields wrote: > > OK, good. So the random nonce is stored with the entry, and the hash > > you can always recalculate from the filename, so if you return entries > > in nonce

Re: [PATCH 3/6] ubifs: Use 64bit readdir cookies

On Thu, Dec 29, 2016 at 05:36:35PM +0100, Richard Weinberger wrote: > Bruce, > > On 29.12.2016 17:15, J. Bruce Fields wrote: > > On Thu, Dec 29, 2016 at 04:49:54PM +0100, Richard Weinberger wrote: > >> Bruce, > >> > >> On 29.12.2016 16:34, J. Bruce Field

Re: [PATCH 3/6] ubifs: Use 64bit readdir cookies

On Thu, Dec 29, 2016 at 05:36:35PM +0100, Richard Weinberger wrote: > Bruce, > > On 29.12.2016 17:15, J. Bruce Fields wrote: > > On Thu, Dec 29, 2016 at 04:49:54PM +0100, Richard Weinberger wrote: > >> Bruce, > >> > >> On 29.12.2016 16:34, J. Bruce Field

Re: [PATCH 3/6] ubifs: Use 64bit readdir cookies

On Thu, Dec 29, 2016 at 04:49:54PM +0100, Richard Weinberger wrote: > Bruce, > > On 29.12.2016 16:34, J. Bruce Fields wrote: > >> That way UBIFS can provide a 64bit readdir() cookie which is required for > >> NFS3. > > > > Sounds good. And if a mat

Re: [PATCH 3/6] ubifs: Use 64bit readdir cookies

On Thu, Dec 29, 2016 at 04:49:54PM +0100, Richard Weinberger wrote: > Bruce, > > On 29.12.2016 16:34, J. Bruce Fields wrote: > >> That way UBIFS can provide a 64bit readdir() cookie which is required for > >> NFS3. > > > > Sounds good. And if a mat

Re: [PATCH 3/6] ubifs: Use 64bit readdir cookies

On Thu, Dec 29, 2016 at 10:19:27AM +0100, Richard Weinberger wrote: > Bruce, > > On 29.12.2016 03:58, J. Bruce Fields wrote: > > On Thu, Dec 01, 2016 at 11:02:18PM +0100, Richard Weinberger wrote: > >> This is the first step to support proper telldir/seekdir() > >

Re: [PATCH 3/6] ubifs: Use 64bit readdir cookies

On Thu, Dec 29, 2016 at 10:19:27AM +0100, Richard Weinberger wrote: > Bruce, > > On 29.12.2016 03:58, J. Bruce Fields wrote: > > On Thu, Dec 01, 2016 at 11:02:18PM +0100, Richard Weinberger wrote: > >> This is the first step to support proper telldir/seekdir() > >

Re: [PATCH 3/6] ubifs: Use 64bit readdir cookies

On Thu, Dec 01, 2016 at 11:02:18PM +0100, Richard Weinberger wrote: > This is the first step to support proper telldir/seekdir() > in UBIFS. > Let's report 64bit cookies in readdir(). The cookie is a combination > of the entry key plus the double hash value. Would it be possible to explain what

Re: [PATCH 3/6] ubifs: Use 64bit readdir cookies

On Thu, Dec 01, 2016 at 11:02:18PM +0100, Richard Weinberger wrote: > This is the first step to support proper telldir/seekdir() > in UBIFS. > Let's report 64bit cookies in readdir(). The cookie is a combination > of the entry key plus the double hash value. Would it be possible to explain what

Re: [PATCH 6/6] ubifs: Wire up NFS support

On Thu, Dec 01, 2016 at 11:02:21PM +0100, Richard Weinberger wrote: > Since we have 64bit readdir cookies and export operations > we can finally enable NFS export support for UBIFS. > > Signed-off-by: Richard Weinberger > --- > fs/ubifs/dir.c | 9 ++--- > fs/ubifs/super.c

Re: [PATCH 6/6] ubifs: Wire up NFS support

On Thu, Dec 01, 2016 at 11:02:21PM +0100, Richard Weinberger wrote: > Since we have 64bit readdir cookies and export operations > we can finally enable NFS export support for UBIFS. > > Signed-off-by: Richard Weinberger > --- > fs/ubifs/dir.c | 9 ++--- > fs/ubifs/super.c | 3 +++ > 2

[GIT PULL] nfsd changes for 4.10

in xprt_rdma_bc_allocate() svcrdma: Remove unused variable in rdma_copy_tail() svcrdma: Break up dprintk format in svc_rdma_accept() svcrdma: Further clean-up of svc_rdma_get_inv_rkey() Fabian Frederick (1): sunrpc: use DEFINE_SPINLOCK() J. Bruce Fields (4): nfsd: clean up supported

[GIT PULL] nfsd changes for 4.10

in xprt_rdma_bc_allocate() svcrdma: Remove unused variable in rdma_copy_tail() svcrdma: Break up dprintk format in svc_rdma_accept() svcrdma: Further clean-up of svc_rdma_get_inv_rkey() Fabian Frederick (1): sunrpc: use DEFINE_SPINLOCK() J. Bruce Fields (4): nfsd: clean up supported

Re: [PATCH v27 03/21] vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD permission flags

On Fri, Dec 02, 2016 at 10:57:42AM +0100, Miklos Szeredi wrote: > On Tue, Oct 11, 2016 at 2:50 PM, Andreas Gruenbacher > wrote: > > Normally, deleting a file requires MAY_WRITE access to the parent > > directory. With richacls, a file may be deleted with MAY_DELETE_CHILD >

Re: [PATCH v27 03/21] vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD permission flags

On Fri, Dec 02, 2016 at 10:57:42AM +0100, Miklos Szeredi wrote: > On Tue, Oct 11, 2016 at 2:50 PM, Andreas Gruenbacher > wrote: > > Normally, deleting a file requires MAY_WRITE access to the parent > > directory. With richacls, a file may be deleted with MAY_DELETE_CHILD > > access > > to the

Re: [PATCH 1/1 linux-next] sunrpc: use DEFINE_SPINLOCK()

Thanks, applying for 4.10.--b. On Sun, Dec 04, 2016 at 01:45:28PM +0100, Fabian Frederick wrote: > Signed-off-by: Fabian Frederick > --- > net/sunrpc/svcauth.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/net/sunrpc/svcauth.c b/net/sunrpc/svcauth.c

Re: [PATCH 1/1 linux-next] sunrpc: use DEFINE_SPINLOCK()

Thanks, applying for 4.10.--b. On Sun, Dec 04, 2016 at 01:45:28PM +0100, Fabian Frederick wrote: > Signed-off-by: Fabian Frederick > --- > net/sunrpc/svcauth.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/net/sunrpc/svcauth.c b/net/sunrpc/svcauth.c > index

Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir

On Tue, Dec 06, 2016 at 02:18:31PM +0100, Andreas Gruenbacher wrote: > On Tue, Dec 6, 2016 at 11:08 AM, Miklos Szeredi wrote: > > On Tue, Dec 6, 2016 at 12:24 AM, Andreas Grünbacher > > wrote: > >> 2016-12-06 0:19 GMT+01:00 Andreas Grünbacher >

Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir

On Tue, Dec 06, 2016 at 02:18:31PM +0100, Andreas Gruenbacher wrote: > On Tue, Dec 6, 2016 at 11:08 AM, Miklos Szeredi wrote: > > On Tue, Dec 6, 2016 at 12:24 AM, Andreas Grünbacher > > wrote: > >> 2016-12-06 0:19 GMT+01:00 Andreas Grünbacher > >> : > > > >>> It's not hard to come up with a

Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir

On Mon, Dec 05, 2016 at 04:36:03PM +0100, Miklos Szeredi wrote: > On Mon, Dec 5, 2016 at 4:19 PM, J. Bruce Fields <bfie...@fieldses.org> wrote: > >> Can NFS people comment on this? Where does the nfs4_acl come from? > > > > This is the interface the NFS client provi

Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir

On Mon, Dec 05, 2016 at 04:36:03PM +0100, Miklos Szeredi wrote: > On Mon, Dec 5, 2016 at 4:19 PM, J. Bruce Fields wrote: > >> Can NFS people comment on this? Where does the nfs4_acl come from? > > > > This is the interface the NFS client provides for applications

Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir

On Mon, Dec 05, 2016 at 10:28:18AM +0100, Miklos Szeredi wrote: > [Added a few more CCs] > > On Mon, Dec 5, 2016 at 1:51 AM, Patrick Plagwitz > wrote: > > Mounting an overlayfs with an NFSv4 lowerdir and an ext4 upperdir causes > > copy_up operations, specifically the

Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir

On Mon, Dec 05, 2016 at 10:28:18AM +0100, Miklos Szeredi wrote: > [Added a few more CCs] > > On Mon, Dec 5, 2016 at 1:51 AM, Patrick Plagwitz > wrote: > > Mounting an overlayfs with an NFSv4 lowerdir and an ext4 upperdir causes > > copy_up operations, specifically the function

Re: [RFC][PATCH 0/4] Enhanced file stat system call

On Thu, Nov 17, 2016 at 04:45:45PM +, David Howells wrote: > One Thousand Gnomes wrote: > > > > (2) Lightweight stat (AT_STATX_DONT_SYNC): Ask for just those details of > > > interest, and allow a network fs to approximate anything not of > > >

Re: [RFC][PATCH 0/4] Enhanced file stat system call

On Thu, Nov 17, 2016 at 04:45:45PM +, David Howells wrote: > One Thousand Gnomes wrote: > > > > (2) Lightweight stat (AT_STATX_DONT_SYNC): Ask for just those details of > > > interest, and allow a network fs to approximate anything not of > > > interest, without going to the

Re: [PATCH v2] fs/nfsd/nfs4callback: Remove deprecated create_singlethread_workqueue

On Wed, Nov 09, 2016 at 02:47:24PM -0500, J. Bruce Fields wrote: > For now I wish we could just like to continue assuming the workqueue > processes only one item at a time. Do we have that now, or do we need > to switch to (looking at workqueue.h...) alloc_ordered workqueue()? Oh, wait,

Re: [PATCH v2] fs/nfsd/nfs4callback: Remove deprecated create_singlethread_workqueue

On Wed, Nov 09, 2016 at 02:47:24PM -0500, J. Bruce Fields wrote: > For now I wish we could just like to continue assuming the workqueue > processes only one item at a time. Do we have that now, or do we need > to switch to (looking at workqueue.h...) alloc_ordered workqueue()? Oh, wait,

<    1   2   3   4   5   6   7   8   9   10   >