Re: [PATCH v2] nfsd: Always lock state exclusively.

On Tue, Jun 14, 2016 at 10:19:49PM -0400, Oleg Drokin wrote: > On Jun 14, 2016, at 2:46 PM, J . Bruce Fields wrote: > > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c > > index fa5fb5aa4847..41b59854c40f 100644 > > --- a/fs/nfsd/nfs4state.c > > +++ b/fs/nfsd/

Re: [PATCH v2] nfsd: Always lock state exclusively.

On Tue, Jun 14, 2016 at 10:19:49PM -0400, Oleg Drokin wrote: > On Jun 14, 2016, at 2:46 PM, J . Bruce Fields wrote: > > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c > > index fa5fb5aa4847..41b59854c40f 100644 > > --- a/fs/nfsd/nfs4state.c > > +++ b/fs/nfsd/

Re: [PATCH v2] nfsd: Always lock state exclusively.

On Tue, Jun 14, 2016 at 11:53:27AM -0400, Oleg Drokin wrote: > > On Jun 14, 2016, at 11:38 AM, J . Bruce Fields wrote: > > > On Sun, Jun 12, 2016 at 09:26:27PM -0400, Oleg Drokin wrote: > >> It used to be the case that state had an rwlock that was locked for

Re: [PATCH v2] nfsd: Always lock state exclusively.

On Tue, Jun 14, 2016 at 11:53:27AM -0400, Oleg Drokin wrote: > > On Jun 14, 2016, at 11:38 AM, J . Bruce Fields wrote: > > > On Sun, Jun 12, 2016 at 09:26:27PM -0400, Oleg Drokin wrote: > >> It used to be the case that state had an rwlock that was locked for

Re: [PATCH v2] nfsd: Always lock state exclusively.

On Tue, Jun 14, 2016 at 11:56:20AM -0400, Oleg Drokin wrote: > > On Jun 14, 2016, at 11:46 AM, J . Bruce Fields wrote: > > > On Sun, Jun 12, 2016 at 09:26:27PM -0400, Oleg Drokin wrote: > >> It used to be the case that state had an rwlock that was locked for

Re: [PATCH v2] nfsd: Always lock state exclusively.

On Tue, Jun 14, 2016 at 11:56:20AM -0400, Oleg Drokin wrote: > > On Jun 14, 2016, at 11:46 AM, J . Bruce Fields wrote: > > > On Sun, Jun 12, 2016 at 09:26:27PM -0400, Oleg Drokin wrote: > >> It used to be the case that state had an rwlock that was locked for

Re: [PATCH v2] nfsd: Always lock state exclusively.

On Sun, Jun 12, 2016 at 09:26:27PM -0400, Oleg Drokin wrote: > It used to be the case that state had an rwlock that was locked for write > by downgrades, but for read for upgrades (opens). Well, the problem is > if there are two competing opens for the same state, they step on > each other toes

Re: [PATCH v2] nfsd: Always lock state exclusively.

On Sun, Jun 12, 2016 at 09:26:27PM -0400, Oleg Drokin wrote: > It used to be the case that state had an rwlock that was locked for write > by downgrades, but for read for upgrades (opens). Well, the problem is > if there are two competing opens for the same state, they step on > each other toes

Re: [PATCH v2] nfsd: Always lock state exclusively.

On Sun, Jun 12, 2016 at 09:26:27PM -0400, Oleg Drokin wrote: > It used to be the case that state had an rwlock that was locked for write > by downgrades, but for read for upgrades (opens). Well, the problem is > if there are two competing opens for the same state, they step on > each other toes

Re: [PATCH v2] nfsd: Always lock state exclusively.

On Sun, Jun 12, 2016 at 09:26:27PM -0400, Oleg Drokin wrote: > It used to be the case that state had an rwlock that was locked for write > by downgrades, but for read for upgrades (opens). Well, the problem is > if there are two competing opens for the same state, they step on > each other toes

Re: [PATCH] nfsd: Close a race between access checking/setting in nfs4_get_vfs_file

On Fri, Jun 10, 2016 at 06:50:33AM -0400, Jeff Layton wrote: > On Fri, 2016-06-10 at 00:18 -0400, Oleg Drokin wrote: > > On Jun 9, 2016, at 5:01 PM, Oleg Drokin wrote: > > > > > Currently there's an unprotected access mode check in > > > nfs4_upgrade_open > > > that then calls nfs4_get_vfs_file

Re: [PATCH] nfsd: Close a race between access checking/setting in nfs4_get_vfs_file

On Fri, Jun 10, 2016 at 06:50:33AM -0400, Jeff Layton wrote: > On Fri, 2016-06-10 at 00:18 -0400, Oleg Drokin wrote: > > On Jun 9, 2016, at 5:01 PM, Oleg Drokin wrote: > > > > > Currently there's an unprotected access mode check in > > > nfs4_upgrade_open > > > that then calls nfs4_get_vfs_file

Re: [PATCH] nfds: Fix NFSD_MDS_PR_KEY on 32-bit by adding ULL postfix

On Sun, Jun 05, 2016 at 06:21:43AM -0400, Jeff Layton wrote: > On Sun, 2016-06-05 at 11:23 +0200, Geert Uytterhoeven wrote: > > On 32-bit: > > > > fs/nfsd/blocklayout.c: In function ‘nfsd4_block_get_device_info_scsi’: > > fs/nfsd/blocklayout.c:337: warning: integer constant is too large

Re: [PATCH] nfds: Fix NFSD_MDS_PR_KEY on 32-bit by adding ULL postfix

On Sun, Jun 05, 2016 at 06:21:43AM -0400, Jeff Layton wrote: > On Sun, 2016-06-05 at 11:23 +0200, Geert Uytterhoeven wrote: > > On 32-bit: > > > > fs/nfsd/blocklayout.c: In function ‘nfsd4_block_get_device_info_scsi’: > > fs/nfsd/blocklayout.c:337: warning: integer constant is too large

Re: kernel BUG at linux-3.16.7-ckt25/fs/dcache.c:2373!

On Fri, Jun 03, 2016 at 11:17:16AM +0200, Philipp Hahn wrote: > Hello, > > Am 02.06.2016 um 22:02 schrieb J. Bruce Fields: > > On Thu, Jun 02, 2016 at 09:51:27AM +0200, Philipp Hahn wrote: > >> probably during heavy IO our file server crashed on a BUG_ON in dache.c, > &

Re: kernel BUG at linux-3.16.7-ckt25/fs/dcache.c:2373!

On Fri, Jun 03, 2016 at 11:17:16AM +0200, Philipp Hahn wrote: > Hello, > > Am 02.06.2016 um 22:02 schrieb J. Bruce Fields: > > On Thu, Jun 02, 2016 at 09:51:27AM +0200, Philipp Hahn wrote: > >> probably during heavy IO our file server crashed on a BUG_ON in dache.c, > &

Re: kernel BUG at linux-3.16.7-ckt25/fs/dcache.c:2373!

On Thu, Jun 02, 2016 at 09:51:27AM +0200, Philipp Hahn wrote: > Hello, > > probably during heavy IO our file server crashed on a BUG_ON in dache.c, > probably triggered by NFS: > > > [ cut here ] > > kernel BUG at > >

Re: kernel BUG at linux-3.16.7-ckt25/fs/dcache.c:2373!

On Thu, Jun 02, 2016 at 09:51:27AM +0200, Philipp Hahn wrote: > Hello, > > probably during heavy IO our file server crashed on a BUG_ON in dache.c, > probably triggered by NFS: > > > [ cut here ] > > kernel BUG at > >

[GIT PULL] nfsd changes for 4.7

svcrdma: Drain QP before freeing svcrdma_xprt svcrdma: Eliminate code duplication in svc_rdma_recvfrom() svcrdma: Generalize svc_rdma_xdr_decode_req() J. Bruce Fields (2): Remove unnecessary allocation svcrpc: autoload rdma module Jeff Layton (1): nfsd: handle seqid

[GIT PULL] nfsd changes for 4.7

svcrdma: Drain QP before freeing svcrdma_xprt svcrdma: Eliminate code duplication in svc_rdma_recvfrom() svcrdma: Generalize svc_rdma_xdr_decode_req() J. Bruce Fields (2): Remove unnecessary allocation svcrpc: autoload rdma module Jeff Layton (1): nfsd: handle seqid

Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available

On Mon, May 09, 2016 at 11:45:43AM +1000, Dave Chinner wrote: > [ OT, but I'll reply anyway :P ] > > On Fri, May 06, 2016 at 02:29:23PM -0400, J. Bruce Fields wrote: > > On Thu, May 05, 2016 at 08:56:02AM +1000, Dave Chinner wrote: > > > In the latest XFS filesys

Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available

On Mon, May 09, 2016 at 11:45:43AM +1000, Dave Chinner wrote: > [ OT, but I'll reply anyway :P ] > > On Fri, May 06, 2016 at 02:29:23PM -0400, J. Bruce Fields wrote: > > On Thu, May 05, 2016 at 08:56:02AM +1000, Dave Chinner wrote: > > > In the latest XFS filesys

Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available

On Thu, May 05, 2016 at 08:56:02AM +1000, Dave Chinner wrote: > IMO, exposing the inode generation number to anyone is a potential > security problem because they are used in file handles. > > Most file handles provided by filesystems are simply an encoding of > the inode number + generation

Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available

On Thu, May 05, 2016 at 08:56:02AM +1000, Dave Chinner wrote: > IMO, exposing the inode generation number to anyone is a potential > security problem because they are used in file handles. > > Most file handles provided by filesystems are simply an encoding of > the inode number + generation

Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available

On Thu, May 05, 2016 at 03:48:16PM -0400, Jeff Layton wrote: > On Thu, 2016-05-05 at 10:09 +1000, NeilBrown wrote: > > On Thu, May 05 2016, Dave Chinner wrote: > > > > > > > > On Fri, Apr 29, 2016 at 01:57:43PM +0100, David Howells wrote: > > > > > > > >  (4) File creation time (st_btime*),

Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available

On Thu, May 05, 2016 at 03:48:16PM -0400, Jeff Layton wrote: > On Thu, 2016-05-05 at 10:09 +1000, NeilBrown wrote: > > On Thu, May 05 2016, Dave Chinner wrote: > > > > > > > > On Fri, Apr 29, 2016 at 01:57:43PM +0100, David Howells wrote: > > > > > > > >  (4) File creation time (st_btime*),

Re: [PATCH 13/15] parallel lookups machinery, part 3

On Sat, Apr 16, 2016 at 01:55:25AM +0100, Al Viro wrote: > From: Al Viro > > We will need to be able to check if there is an in-lookup > dentry with matching parent/name. Right now it's impossible, > but as soon as start locking directories shared such beasts > will

Re: [PATCH 13/15] parallel lookups machinery, part 3

On Sat, Apr 16, 2016 at 01:55:25AM +0100, Al Viro wrote: > From: Al Viro > > We will need to be able to check if there is an in-lookup > dentry with matching parent/name. Right now it's impossible, > but as soon as start locking directories shared such beasts > will appear. > > Add a secondary

Re: [PATCH 07/15] reconnect_one(): use lookup_one_len_unlocked()

On Sat, Apr 16, 2016 at 01:55:19AM +0100, Al Viro wrote: > From: Al Viro > > ... and explain the non-obvious logics in case when lookup yields > a different dentry. ACK to this independent of the rest of the series, my only minor gripe is that the point made in this new

Re: [PATCH 07/15] reconnect_one(): use lookup_one_len_unlocked()

On Sat, Apr 16, 2016 at 01:55:19AM +0100, Al Viro wrote: > From: Al Viro > > ... and explain the non-obvious logics in case when lookup yields > a different dentry. ACK to this independent of the rest of the series, my only minor gripe is that the point made in this new comment is also made at

Re: [PATCH] nfds: Fix NFSD_MDS_PR_KEY on 32-bit by adding ULL postfix

On Fri, Mar 25, 2016 at 07:04:22PM +0100, Christoph Hellwig wrote: > Looks fine, thanks! > > Reviewed-by: Christoph Hellwig Thanks, applying for 4.6.--b.

Re: [PATCH] nfds: Fix NFSD_MDS_PR_KEY on 32-bit by adding ULL postfix

On Fri, Mar 25, 2016 at 07:04:22PM +0100, Christoph Hellwig wrote: > Looks fine, thanks! > > Reviewed-by: Christoph Hellwig Thanks, applying for 4.6.--b.

[GIT PULL] nfsd changes for 4.6, take 2

for RPC-over-RDMA server send CQs J. Bruce Fields (4): nfsd4: fix bad bounds checking nfsd4: resfh unused in nfsd4_secinfo nfsd: fix deadlock secinfo+readdir compound nfsd: better layoutupdate bounds-checking Kinglong Mee (1): nfsd: Fix a memory leak when meeting

[GIT PULL] nfsd changes for 4.6, take 2

for RPC-over-RDMA server send CQs J. Bruce Fields (4): nfsd4: fix bad bounds checking nfsd4: resfh unused in nfsd4_secinfo nfsd: fix deadlock secinfo+readdir compound nfsd: better layoutupdate bounds-checking Kinglong Mee (1): nfsd: Fix a memory leak when meeting

Re: [GIT PULL] nfsd changes for 4.6

On Thu, Mar 24, 2016 at 03:00:55PM -0400, Trond Myklebust wrote: > On Thu, Mar 24, 2016 at 9:35 AM, J. Bruce Fields <bfie...@fieldses.org> wrote: > > Please pull nfsd changes for 4.6 from > > > > git://linux-nfs.org/~bfie

Re: [GIT PULL] nfsd changes for 4.6

On Thu, Mar 24, 2016 at 03:00:55PM -0400, Trond Myklebust wrote: > On Thu, Mar 24, 2016 at 9:35 AM, J. Bruce Fields wrote: > > Please pull nfsd changes for 4.6 from > > > > git://linux-nfs.org/~bfields/li

[GIT PULL] nfsd changes for 4.6

to return ERR_CHUNK svcrdma: Remove close_out exit path svcrdma: Use new CQ API for RPC-over-RDMA server receive CQs svcrdma: Use new CQ API for RPC-over-RDMA server send CQs J. Bruce Fields (3): nfsd4: fix bad bounds checking nfsd4: resfh unused in nfsd4_secinfo

[GIT PULL] nfsd changes for 4.6

to return ERR_CHUNK svcrdma: Remove close_out exit path svcrdma: Use new CQ API for RPC-over-RDMA server receive CQs svcrdma: Use new CQ API for RPC-over-RDMA server send CQs J. Bruce Fields (3): nfsd4: fix bad bounds checking nfsd4: resfh unused in nfsd4_secinfo

Re: [RFD] workqueue: WQ_MEM_RECLAIM usage in network drivers

On Fri, Mar 18, 2016 at 04:46:23PM -0400, Tejun Heo wrote: > Hello, Jeff. > > On Thu, Mar 17, 2016 at 09:32:16PM -0400, Jeff Layton wrote: > > > * Are network devices expected to be able to serve as a part of > > > storage stack which is depended upon for memory reclamation? > > > > I think

Re: [RFD] workqueue: WQ_MEM_RECLAIM usage in network drivers

On Fri, Mar 18, 2016 at 04:46:23PM -0400, Tejun Heo wrote: > Hello, Jeff. > > On Thu, Mar 17, 2016 at 09:32:16PM -0400, Jeff Layton wrote: > > > * Are network devices expected to be able to serve as a part of > > > storage stack which is depended upon for memory reclamation? > > > > I think

Re: [PATCH v18 19/22] richacl: Add richacl xattr handler

On Tue, Mar 15, 2016 at 12:10:14AM -0700, Christoph Hellwig wrote: > On Fri, Mar 11, 2016 at 09:19:05AM -0500, J. Bruce Fields wrote: > > On Fri, Mar 11, 2016 at 06:17:35AM -0800, Christoph Hellwig wrote: > > > On Mon, Feb 29, 2016 at 09:17:24AM +0100, Andreas Gruenbacher

Re: [PATCH v18 19/22] richacl: Add richacl xattr handler

On Tue, Mar 15, 2016 at 12:10:14AM -0700, Christoph Hellwig wrote: > On Fri, Mar 11, 2016 at 09:19:05AM -0500, J. Bruce Fields wrote: > > On Fri, Mar 11, 2016 at 06:17:35AM -0800, Christoph Hellwig wrote: > > > On Mon, Feb 29, 2016 at 09:17:24AM +0100, Andreas Gruenbacher

Re: [PATCH] nfsd: recover: fix memory leak

On Mon, Mar 07, 2016 at 03:40:03PM +0530, Sudip Mukherjee wrote: > nfsd4_cltrack_grace_start() will allocate the memory for grace_start but > when we returned due to error we missed freeing it. Thanks, applying for 4.6.--b. > > Signed-off-by: Sudip Mukherjee >

Re: [PATCH] nfsd: recover: fix memory leak

On Mon, Mar 07, 2016 at 03:40:03PM +0530, Sudip Mukherjee wrote: > nfsd4_cltrack_grace_start() will allocate the memory for grace_start but > when we returned due to error we missed freeing it. Thanks, applying for 4.6.--b. > > Signed-off-by: Sudip Mukherjee > --- > fs/nfsd/nfs4recover.c | 1

Re: [PATCH v18 19/22] richacl: Add richacl xattr handler

On Fri, Mar 11, 2016 at 06:17:35AM -0800, Christoph Hellwig wrote: > On Mon, Feb 29, 2016 at 09:17:24AM +0100, Andreas Gruenbacher wrote: > > Add richacl xattr handler implementing the xattr operations based on the > > get_richacl and set_richacl inode operations. > > Given all the issues with

Re: [PATCH v18 19/22] richacl: Add richacl xattr handler

On Fri, Mar 11, 2016 at 06:17:35AM -0800, Christoph Hellwig wrote: > On Mon, Feb 29, 2016 at 09:17:24AM +0100, Andreas Gruenbacher wrote: > > Add richacl xattr handler implementing the xattr operations based on the > > get_richacl and set_richacl inode operations. > > Given all the issues with

Re: [PATCH v18 00/22] Richacls (Core and Ext4)

On Fri, Mar 11, 2016 at 06:01:34AM -0800, Christoph Hellwig wrote: > On Mon, Feb 29, 2016 at 09:17:05AM +0100, Andreas Gruenbacher wrote: > > Al, > > > > could you please make sure you are happy with the current version of the > > richacl patch queue for the next merge window? > > I'm still not

Re: [PATCH v18 00/22] Richacls (Core and Ext4)

On Fri, Mar 11, 2016 at 06:01:34AM -0800, Christoph Hellwig wrote: > On Mon, Feb 29, 2016 at 09:17:05AM +0100, Andreas Gruenbacher wrote: > > Al, > > > > could you please make sure you are happy with the current version of the > > richacl patch queue for the next merge window? > > I'm still not

[GIT PULL] nfsd bugfix for 4.5

Please pull an nfsd bugfix for 4.5 from git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.5-1 One fix for a bug that could cause a NULL write past the end of a buffer in case of unusually long writes to some system interfaces used by mountd and other nfs support utilities. --b. Stefan

[GIT PULL] nfsd bugfix for 4.5

Please pull an nfsd bugfix for 4.5 from git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.5-1 One fix for a bug that could cause a NULL write past the end of a buffer in case of unusually long writes to some system interfaces used by mountd and other nfs support utilities. --b. Stefan

Re: call_usermodehelper in containers

On Tue, Feb 23, 2016 at 10:55:30AM +0800, Ian Kent wrote: > You know, wrt. the mechanism Oleg suggested, I've been wondering if it's > even necessary to capture process template information for execution. > > Isn't the main issue the execution of unknown arbitrary objects getting > access to a

Re: call_usermodehelper in containers

On Tue, Feb 23, 2016 at 10:55:30AM +0800, Ian Kent wrote: > You know, wrt. the mechanism Oleg suggested, I've been wondering if it's > even necessary to capture process template information for execution. > > Isn't the main issue the execution of unknown arbitrary objects getting > access to a

Re: richacl(7) man page review comments

On Sun, Feb 07, 2016 at 05:35:46PM +0100, Michael Kerrisk (man-pages) wrote: > > This permission is always implicitly granted. > > .HP > > .B write_attributes > > .RB ( A ): > > Change the times associated with a file or directory to an arbitrary value. > > This permission is always implicitly

Re: richacl(7) man page review comments

On Sun, Feb 07, 2016 at 05:35:46PM +0100, Michael Kerrisk (man-pages) wrote: > > This permission is always implicitly granted. > > .HP > > .B write_attributes > > .RB ( A ): > > Change the times associated with a file or directory to an arbitrary value. > > This permission is always implicitly

Re: kernel pruning script..

chine every time, because it will just be there with the > kernel source tree (and without a kernel source tree it's not needed). > > Linus > > On Wed, Jul 10, 2013 at 1:54 PM, J. Bruce Fields wrote: > > > > I run this by hand every now and then. I'm probab

Re: kernel pruning script..

chine every time, because it will just be there with the > kernel source tree (and without a kernel source tree it's not needed). > > Linus > > On Wed, Jul 10, 2013 at 1:54 PM, J. Bruce Fields <bfie...@fieldses.org> wrote: > > > > I run this by hand

Re: [PATCH/RFC] VFS: Improve fairness when locking the per-superblock s_anon list

On Tue, Feb 02, 2016 at 03:10:43PM +1100, NeilBrown wrote: > On Tue, Feb 02 2016, J. Bruce Fields wrote: > > > On Fri, Jan 29, 2016 at 11:17:43AM +1100, NeilBrown wrote: > >> bit-spin-locks, as used for dcache hash chains, are not fair. > >> This is not a pro

Re: [PATCH/RFC] VFS: Improve fairness when locking the per-superblock s_anon list

On Tue, Feb 02, 2016 at 03:10:43PM +1100, NeilBrown wrote: > On Tue, Feb 02 2016, J. Bruce Fields wrote: > > > On Fri, Jan 29, 2016 at 11:17:43AM +1100, NeilBrown wrote: > >> bit-spin-locks, as used for dcache hash chains, are not fair. > >> This is not a pro

Re: [PATCH/RFC] VFS: Improve fairness when locking the per-superblock s_anon list

On Fri, Jan 29, 2016 at 11:17:43AM +1100, NeilBrown wrote: > bit-spin-locks, as used for dcache hash chains, are not fair. > This is not a problem for the dcache hash table as different CPUs are > likely to access different entries in the hash table so high contention > is not expected. > However

Re: [LKP] [lkp] [locks] 7f3697e24d: +35.1% will-it-scale.per_thread_ops

On Fri, Jan 29, 2016 at 10:52:20AM +0800, Huang, Ying wrote: > Jeff Layton writes: > > > On Fri, 29 Jan 2016 09:32:19 +0800 > > kernel test robot wrote: > > > >> FYI, we noticed the below changes on > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > >> commit

Re: [PATCH/RFC] VFS: Improve fairness when locking the per-superblock s_anon list

On Fri, Jan 29, 2016 at 11:17:43AM +1100, NeilBrown wrote: > bit-spin-locks, as used for dcache hash chains, are not fair. > This is not a problem for the dcache hash table as different CPUs are > likely to access different entries in the hash table so high contention > is not expected. > However

Re: [LKP] [lkp] [locks] 7f3697e24d: +35.1% will-it-scale.per_thread_ops

On Fri, Jan 29, 2016 at 10:52:20AM +0800, Huang, Ying wrote: > Jeff Layton writes: > > > On Fri, 29 Jan 2016 09:32:19 +0800 > > kernel test robot wrote: > > > >> FYI, we noticed the below changes on > >> > >>

Re: linux-next: manual merge of the rdma tree with the nfsd tree

On Wed, Jan 06, 2016 at 07:01:14AM -0500, Chuck Lever wrote: > Part of the plan was that Doug's tree would be merged before > Bruce's. But the above problem description looks like the > maintainer trees were merged into linux-next in the other order. The order makes no difference. The problem is

Re: linux-next: manual merge of the rdma tree with the nfsd tree

On Wed, Jan 06, 2016 at 07:01:14AM -0500, Chuck Lever wrote: > Part of the plan was that Doug's tree would be merged before > Bruce's. But the above problem description looks like the > maintainer trees were merged into linux-next in the other order. The order makes no difference. The problem is

Re: [PATCH] lockd: constify nlmsvc_binding structure

On Wed, Dec 23, 2015 at 10:25:13PM +0100, Julia Lawall wrote: > The nlmsvc_binding structure is never modified, so declare it as const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall > > --- > > This assumes that whoever takes advantage of the EXPORT_SYMBOL will also >

Re: [PATCH 3/3] lockd: use to_delayed_work

On Fri, Jan 01, 2016 at 10:06:29PM +0800, Geliang Tang wrote: > Use to_delayed_work() instead of open-coding it. Thanks, applying 2/3 and 3/3 for 4.5.--b. > > Signed-off-by: Geliang Tang > --- > fs/lockd/svc.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git

Re: linux-next: manual merge of the rdma tree with the nfsd tree

On Sun, Jan 03, 2016 at 09:53:20PM -0500, Doug Ledford wrote: > On 01/03/2016 08:44 PM, Stephen Rothwell wrote: > > Hi all, > > > > On Thu, 31 Dec 2015 13:30:22 +1100 Stephen Rothwell > > wrote: > >> > >> Hi Doug, > >> > >> Today's linux-next merge of the rdma tree got conflicts in a quite a >

Re: linux-next: manual merge of the rdma tree with the nfsd tree

On Sun, Jan 03, 2016 at 09:53:20PM -0500, Doug Ledford wrote: > On 01/03/2016 08:44 PM, Stephen Rothwell wrote: > > Hi all, > > > > On Thu, 31 Dec 2015 13:30:22 +1100 Stephen Rothwell > > wrote: > >> > >> Hi Doug, > >> > >> Today's linux-next merge of the rdma tree got

Re: [PATCH 3/3] lockd: use to_delayed_work

On Fri, Jan 01, 2016 at 10:06:29PM +0800, Geliang Tang wrote: > Use to_delayed_work() instead of open-coding it. Thanks, applying 2/3 and 3/3 for 4.5.--b. > > Signed-off-by: Geliang Tang > --- > fs/lockd/svc.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > >

Re: [PATCH] lockd: constify nlmsvc_binding structure

On Wed, Dec 23, 2015 at 10:25:13PM +0100, Julia Lawall wrote: > The nlmsvc_binding structure is never modified, so declare it as const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall > > --- > > This assumes that whoever takes advantage of the

[GIT PULL] nfsd fix for 4.4

Please pull an nfsd change for 4.4: git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.4-1 Just one fix for a NFSv4 callback bug introduced in 4.4. Jeff Layton (1): nfsd: don't hold ls_mutex across a layout recall

[GIT PULL] nfsd fix for 4.4

Please pull an nfsd change for 4.4: git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.4-1 Just one fix for a NFSv4 callback bug introduced in 4.4. Jeff Layton (1): nfsd: don't hold ls_mutex across a layout recall

Re: [RFC][PATCH 00/12] Enhanced file stat system call

On Fri, Nov 20, 2015 at 04:28:35PM +, David Howells wrote: > Martin Steigerwald wrote: > > > Any plans to add limitations of filesystem to the call like maximum file > > size? I know its mostly relevant for just for FAT32, but on any account > > rather than trying to write 4 GiB and then

Re: [RFC][PATCH 00/12] Enhanced file stat system call

On Fri, Nov 20, 2015 at 04:28:35PM +, David Howells wrote: > Martin Steigerwald wrote: > > > Any plans to add limitations of filesystem to the call like maximum file > > size? I know its mostly relevant for just for FAT32, but on any account > > rather than trying to

Re: [PATCH] nfsd: constify nfsd4_callback_ops structure

On Sun, Nov 22, 2015 at 09:57:42AM -0800, Christoph Hellwig wrote: > Thanks, this looks good. I should have add the const from the start. > > Reviewed-by: Christoph Hellwig Thanks, applying for 4.5.--b. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: [PATCH] nfsd: recover: constify nfsd4_client_tracking_ops structures

On Sun, Nov 22, 2015 at 07:25:12AM -0500, Jeff Layton wrote: > On Sun, 22 Nov 2015 08:22:10 +0100 > Julia Lawall wrote: > > > The nfsd4_client_tracking_ops structures are never modified, so declare > > them as const. > > > > Done with the help of Coccinelle. > > > > Signed-off-by: Julia Lawall

Re: [PATCH] nfsd: constify nfsd4_callback_ops structure

On Sun, Nov 22, 2015 at 09:57:42AM -0800, Christoph Hellwig wrote: > Thanks, this looks good. I should have add the const from the start. > > Reviewed-by: Christoph Hellwig Thanks, applying for 4.5.--b. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

Re: [PATCH] nfsd: recover: constify nfsd4_client_tracking_ops structures

On Sun, Nov 22, 2015 at 07:25:12AM -0500, Jeff Layton wrote: > On Sun, 22 Nov 2015 08:22:10 +0100 > Julia Lawall wrote: > > > The nfsd4_client_tracking_ops structures are never modified, so declare > > them as const. > > > > Done with the help of Coccinelle. > > > >

Re: [PATCH v3 0/7] User namespace mount updates

On Tue, Nov 17, 2015 at 07:30:12PM +, Al Viro wrote: > On Tue, Nov 17, 2015 at 02:02:09PM -0500, Austin S Hemmelgarn wrote: > > > >_Static_ attacks, or change-image-under-mounted-fs attacks? > > To properly protect against attacks on mounted filesystems, we'd > > need some new concept of a

Re: [PATCH v3 0/7] User namespace mount updates

On Tue, Nov 17, 2015 at 07:30:12PM +, Al Viro wrote: > On Tue, Nov 17, 2015 at 02:02:09PM -0500, Austin S Hemmelgarn wrote: > > > >_Static_ attacks, or change-image-under-mounted-fs attacks? > > To properly protect against attacks on mounted filesystems, we'd > > need some new concept of a

[GIT PULL] nfsd changes for 4.4

/ open upgrade stateids Andrey Ryabinin (2): lockd: create NSM handles per net namespace lockd: get rid of reference-counted NSM RPC clients Arnd Bergmann (1): sunrpc: avoid warning in gss_key_timeout J. Bruce Fields (3): nfsd: fix clid_inuse on mount with security change

[GIT PULL] nfsd changes for 4.4

/ open upgrade stateids Andrey Ryabinin (2): lockd: create NSM handles per net namespace lockd: get rid of reference-counted NSM RPC clients Arnd Bergmann (1): sunrpc: avoid warning in gss_key_timeout J. Bruce Fields (3): nfsd: fix clid_inuse on mount with security change

Re: [PATCH v15 00/22] Richacls (Core and Ext4)

On Tue, Nov 10, 2015 at 06:58:19PM +0100, Andreas Gruenbacher wrote: > On Tue, Nov 10, 2015 at 6:07 PM, J. Bruce Fields wrote: > > On Tue, Nov 10, 2015 at 10:43:46AM -0600, Steve French wrote: > >> I don't have strong disagreement with using pseudo-xattrs to > >> stor

Re: [PATCH v15 00/22] Richacls (Core and Ext4)

On Tue, Nov 10, 2015 at 10:43:46AM -0600, Steve French wrote: > On Tue, Nov 10, 2015 at 6:39 AM, Andreas Gruenbacher > wrote: > > On Tue, Nov 10, 2015 at 12:29 PM, Christoph Hellwig > > wrote: > >> On Mon, Nov 09, 2015 at 12:08:41PM +0100, Andreas Gruenbacher wrote: > >>> Here is another update

Re: [PATCH v15 00/22] Richacls (Core and Ext4)

On Tue, Nov 10, 2015 at 10:43:46AM -0600, Steve French wrote: > On Tue, Nov 10, 2015 at 6:39 AM, Andreas Gruenbacher > wrote: > > On Tue, Nov 10, 2015 at 12:29 PM, Christoph Hellwig > > wrote: > >> On Mon, Nov 09, 2015 at 12:08:41PM +0100, Andreas

Re: [PATCH v15 00/22] Richacls (Core and Ext4)

On Tue, Nov 10, 2015 at 06:58:19PM +0100, Andreas Gruenbacher wrote: > On Tue, Nov 10, 2015 at 6:07 PM, J. Bruce Fields <bfie...@fieldses.org> wrote: > > On Tue, Nov 10, 2015 at 10:43:46AM -0600, Steve French wrote: > >> I don't have strong disagreement with using pse

Re: [PATCH/RFC] make btrfs subvol mounts appear in /proc/mounts

On Wed, Oct 28, 2015 at 07:25:10AM +0900, Neil Brown wrote: > > If you create a subvolume in btrfs and access it (by name) without > mounting it, then the subvolume looks like a separate mount to some > extent, returning a different st_dev to stat(), but it doesn't look like > a separate mount in

Re: [PATCH/RFC] make btrfs subvol mounts appear in /proc/mounts

On Wed, Oct 28, 2015 at 07:25:10AM +0900, Neil Brown wrote: > > If you create a subvolume in btrfs and access it (by name) without > mounting it, then the subvolume looks like a separate mount to some > extent, returning a different st_dev to stat(), but it doesn't look like > a separate mount in

Re: [PATCHv2] Documentation: add new description of path-name lookup.

On Mon, Oct 26, 2015 at 03:35:54PM +0900, Neil Brown wrote: > From c38784b876a181eda9a5687e618749157dc96a0e Mon Sep 17 00:00:00 2001 > From: NeilBrown > Date: Sat, 25 Jul 2015 10:24:41 +1000 > Subject: [PATCH] Documentation: add new description of path-name lookup. > > This document is based on

Re: [PATCHv2] Documentation: add new description of path-name lookup.

On Mon, Oct 26, 2015 at 03:35:54PM +0900, Neil Brown wrote: > From c38784b876a181eda9a5687e618749157dc96a0e Mon Sep 17 00:00:00 2001 > From: NeilBrown > Date: Sat, 25 Jul 2015 10:24:41 +1000 > Subject: [PATCH] Documentation: add new description of path-name lookup. > > This

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

On Fri, Oct 23, 2015 at 04:14:10AM +, Kosuke Tatsukawa wrote: > J. Bruce Fields wrote: > > On Fri, Oct 16, 2015 at 02:28:10AM +, Kosuke Tatsukawa wrote: > >> Tatsukawa Kosuke wrote: > >> > J. Bruce Fields wrote: > >> >> On Thu, Oct 15, 201

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

On Fri, Oct 23, 2015 at 04:14:10AM +, Kosuke Tatsukawa wrote: > J. Bruce Fields wrote: > > On Fri, Oct 16, 2015 at 02:28:10AM +, Kosuke Tatsukawa wrote: > >> Tatsukawa Kosuke wrote: > >> > J. Bruce Fields wrote: > >> >> On Thu, Oct 15, 201

Re: [PATCH V2 0/3] Minor cleanup for locks API

On Thu, Oct 22, 2015 at 01:38:12PM -0400, Benjamin Coddington wrote: > NFS has recently been moving things around to cope with the situation where > a struct file may not be available during an unlock. That work has > presented an opportunity to do a minor cleanup on the locks API. > > Users of

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

On Fri, Oct 16, 2015 at 02:28:10AM +, Kosuke Tatsukawa wrote: > Tatsukawa Kosuke wrote: > > J. Bruce Fields wrote: > >> On Thu, Oct 15, 2015 at 11:44:20AM +, Kosuke Tatsukawa wrote: > >>> Tatsukawa Kosuke wrote: > >>> > J. Bruce Fields wrote: &

Re: [PATCH V2 0/3] Minor cleanup for locks API

On Thu, Oct 22, 2015 at 01:38:12PM -0400, Benjamin Coddington wrote: > NFS has recently been moving things around to cope with the situation where > a struct file may not be available during an unlock. That work has > presented an opportunity to do a minor cleanup on the locks API. > > Users of

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

On Fri, Oct 16, 2015 at 02:28:10AM +, Kosuke Tatsukawa wrote: > Tatsukawa Kosuke wrote: > > J. Bruce Fields wrote: > >> On Thu, Oct 15, 2015 at 11:44:20AM +, Kosuke Tatsukawa wrote: > >>> Tatsukawa Kosuke wrote: > >>> > J. Bruce Fields wrote: &

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

On Thu, Oct 15, 2015 at 11:44:20AM +, Kosuke Tatsukawa wrote: > Tatsukawa Kosuke wrote: > > J. Bruce Fields wrote: > >> Thanks for the detailed investigation. > >> > >> I think it would be worth adding a comment if that might help someone > >>

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

On Thu, Oct 15, 2015 at 11:44:20AM +, Kosuke Tatsukawa wrote: > Tatsukawa Kosuke wrote: > > J. Bruce Fields wrote: > >> Thanks for the detailed investigation. > >> > >> I think it would be worth adding a comment if that might help someone > >>

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

On Wed, Oct 14, 2015 at 03:57:13AM +, Kosuke Tatsukawa wrote: > J. Bruce Fields wrote: > > 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 w

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

On Wed, Oct 14, 2015 at 03:57:13AM +, Kosuke Tatsukawa wrote: > J. Bruce Fields wrote: > > 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 w

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