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: ANNOUNCE: mdadm 4.0 - A tool for managing md Soft RAID under Linux

ble at: http://anduin.linuxfromscratch.org/~bdubbs/mdadm-logs/ -- Bruce Dubbs linuxfromscratch.org

Re: ANNOUNCE: mdadm 4.0 - A tool for managing md Soft RAID under Linux

ble at: http://anduin.linuxfromscratch.org/~bdubbs/mdadm-logs/ -- Bruce Dubbs linuxfromscratch.org

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: Designated initializers, struct randomization and addressing?

As a tangential party, I am a bit curious: does the randomization plugin result in a compact structure? I ask because I know many/most programmers don't bother with it and so doing so ought to make the data more compact. On Tue, Jan 3, 2017 at 3:47 PM, Kees Cook wrote: >>

Re: Designated initializers, struct randomization and addressing?

As a tangential party, I am a bit curious: does the randomization plugin result in a compact structure? I ask because I know many/most programmers don't bother with it and so doing so ought to make the data more compact. On Tue, Jan 3, 2017 at 3:47 PM, Kees Cook wrote: >> how is the code to be

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

Re: [PATCH] staging: lustre: ldlm: use designated initializers

> > "{ NULL }" is valid ISO C, but unfortunately "{}" is not. Just make the thing "static const" and don't use an initializer.

Re: [PATCH] staging: lustre: ldlm: use designated initializers

> > "{ NULL }" is valid ISO C, but unfortunately "{}" is not. Just make the thing "static const" and don't use an initializer.

Re: [PATCH] staging: lustre: ldlm: use designated initializers

On Mon, Dec 19, 2016 at 8:22 AM, James Simmons >> --- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c >> +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c >> @@ -143,7 +143,7 @@ static int ldlm_process_flock_lock(struct ldlm_lock >> *req, __u64 *flags, >> int added = (mode == LCK_NL);

Re: [PATCH] staging: lustre: ldlm: use designated initializers

On Mon, Dec 19, 2016 at 8:22 AM, James Simmons >> --- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c >> +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c >> @@ -143,7 +143,7 @@ static int ldlm_process_flock_lock(struct ldlm_lock >> *req, __u64 *flags, >> int added = (mode == LCK_NL);

[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,

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

On Wed, Nov 09, 2016 at 12:33:35PM -0500, Jeff Layton wrote: > On Wed, 2016-11-09 at 11:27 -0500, J. Bruce Fields wrote: > > On Wed, Nov 09, 2016 at 08:18:08AM -0500, Jeff Layton wrote: > > > > > > On Tue, 2016-11-08 at 20:27 -0500, J. Bruce Fields wrote: > >

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

On Wed, Nov 09, 2016 at 12:33:35PM -0500, Jeff Layton wrote: > On Wed, 2016-11-09 at 11:27 -0500, J. Bruce Fields wrote: > > On Wed, Nov 09, 2016 at 08:18:08AM -0500, Jeff Layton wrote: > > > > > > On Tue, 2016-11-08 at 20:27 -0500, J. Bruce Fields wrote: > >

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

On Wed, Nov 09, 2016 at 08:18:08AM -0500, Jeff Layton wrote: > On Tue, 2016-11-08 at 20:27 -0500, J. Bruce Fields wrote: > > On Tue, Nov 08, 2016 at 05:52:21PM -0500, Tejun Heo wrote: > > > > > > Hello, Bruce. > > > > > > On Tue, Nov 08, 20

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

On Wed, Nov 09, 2016 at 08:18:08AM -0500, Jeff Layton wrote: > On Tue, 2016-11-08 at 20:27 -0500, J. Bruce Fields wrote: > > On Tue, Nov 08, 2016 at 05:52:21PM -0500, Tejun Heo wrote: > > > > > > Hello, Bruce. > > > > > > On Tue, Nov 08, 20

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

On Tue, Nov 08, 2016 at 05:52:21PM -0500, Tejun Heo wrote: > Hello, Bruce. > > On Tue, Nov 08, 2016 at 04:39:11PM -0500, J. Bruce Fields wrote: > > Apologies, just cleaning out old mail and finding some I should have > > responded to long ago: > > > > On Wed,

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

On Tue, Nov 08, 2016 at 05:52:21PM -0500, Tejun Heo wrote: > Hello, Bruce. > > On Tue, Nov 08, 2016 at 04:39:11PM -0500, J. Bruce Fields wrote: > > Apologies, just cleaning out old mail and finding some I should have > > responded to long ago: > > > > On Wed,

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

Apologies, just cleaning out old mail and finding some I should have responded to long ago: On Wed, Aug 31, 2016 at 02:23:48AM +0530, Bhaktipriya Shridhar wrote: > The workqueue "callback_wq" queues a single work item >cb_work per > nfsd4_callback instance and thus, it doesn't require execution

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

Apologies, just cleaning out old mail and finding some I should have responded to long ago: On Wed, Aug 31, 2016 at 02:23:48AM +0530, Bhaktipriya Shridhar wrote: > The workqueue "callback_wq" queues a single work item >cb_work per > nfsd4_callback instance and thus, it doesn't require execution

Re: [PATCH] nfsd: constify reply_cache_stats_operations structure

ruct file_operations reply_cache_stats_operations = { > > +static const struct file_operations reply_cache_stats_operations = { > >   .open = nfsd_reply_cache_stats_open, > >   .read = seq_read, > >   .llseek = seq_lseek, > > > >

Re: [PATCH] nfsd: constify reply_cache_stats_operations structure

ile_operations reply_cache_stats_operations = { > > +static const struct file_operations reply_cache_stats_operations = { > >   .open = nfsd_reply_cache_stats_open, > >   .read = seq_read, > >   .llseek = seq_lseek, > > > > I'm pretty sure Bruce will pick this up for v4.9: Except, for some reason it's been languishing in my inbox. Apologies, applying --b. > > Reviewed-by: Jeff Layton

[GIT PULL] nfsd bugfixes for 4.9

on the stack). Chuck Lever (2): svcrdma: backchannel cannot share a page for send and rcv buffers nfsd: Fix general protection fault in release_lock_stateid() J. Bruce Fields (1): sunrpc: don't pass on-stack memory

[GIT PULL] nfsd bugfixes for 4.9

on the stack). Chuck Lever (2): svcrdma: backchannel cannot share a page for send and rcv buffers nfsd: Fix general protection fault in release_lock_stateid() J. Bruce Fields (1): sunrpc: don't pass on-stack memory

Re: [PATCH] nfsd: more robust allocation failure handling in nfsd_reply_cache_init

On Tue, Aug 30, 2016 at 11:23:36AM -0700, Linus Torvalds wrote: > On Tue, Aug 30, 2016 at 4:48 AM, Jeff Layton wrote: > > > > While this would be good to get in, I don't see any particular urgency > > here. This seems like it'd be reasonable for v4.9. > > Agreed, looks ok to

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