From: "J. Bruce Fields"
There's some odd logic in nfsd_create() that allows it to be called with
the parent directory either locked or unlocked. The only already-locked
caller is NFSv2's nfsd_proc_create(). It's less confusing to split out
the unlocked case into a se
From: "J. Bruce Fields"
I'm not sure why this was added. It doesn't seem necessary, and no
other caller does this.
Signed-off-by: J. Bruce Fields
---
fs/nfsd/vfs.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index fba8e7e521e0.
From: "J. Bruce Fields"
lookup_one_len already has this check.
The only effect of this patch is to return access instead of perm in the
0-length-filename case. I actually prefer nfserr_perm (or _inval?), but
I doubt anyone cares.
The isdotent check seems redundant too, but I worry
n the local
cache or not.
Another positive side effect is certain programs only expect
EEXIST in that case even despite POSIX allowing any valid
error to be returned.
Signed-off-by: Oleg Drokin
Signed-off-by: J. Bruce Fields
---
fs/nfsd/nfs4proc.c | 6 +-
fs/nfsd/vfs.c | 11 ++-
2
From: "J. Bruce Fields"
Minor cleanup, no change in behavior.
Signed-off-by: J. Bruce Fields
---
fs/nfsd/vfs.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index d45b39b408a1..cd06c6511cfc 100644
--- a/fs/nfsd/vfs.
From: "J. Bruce Fields"
On Fri, Jul 22, 2016 at 11:13:20AM -0400, Oleg Drokin wrote:
> Hm, in fact indeed. I was just too worked up about the client side,
> but on the server side there was a real lookup already, so it does
> look workable.
So I end up with the following.
From: "J. Bruce Fields"
We need an fh_verify to make sure we at least have a dentry, but actual
permission checks happen later.
Signed-off-by: J. Bruce Fields
---
fs/nfsd/nfs4proc.c | 7 +--
fs/nfsd/vfs.c | 6 +-
2 files changed, 2 insertions(+), 11 deletions(-)
diff
From: "J. Bruce Fields"
vfs_{create,mkdir,mknod} each begin with a call to may_create(), which
returns EEXIST if the object already exists.
This check is therefore unnecessary.
(In the NFSv2 case, nfsd_proc_create also has such a check. Contrary to
RFC 1094, our code seems to beli
On Wed, Sep 21, 2016 at 09:20:10AM -0400, Jeff Layton wrote:
> On Wed, 2016-09-21 at 15:33 +0300, Vasily Averin wrote:
> > By design notifier can be registered once only,
> > however nfsd registers the same inetaddr notifiers per net-namespace.
> > When this happen it corrupts list of notifiers,
>
nfsd: Fix some indent inconsistancy
Chuck Lever (1):
nfsd: Close race between nfsd4_release_lockowner and nfsd4_lock
Dan Carpenter (1):
nfsd: remove some dead code in nfsd_create_locked()
J. Bruce Fields (6):
nfsd: remove redundant zero-length check from create
nfsd: check
Thanks, applied for 4.15.--b.
On Mon, Oct 16, 2017 at 02:40:21PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The function _svc_create_xprt is local to the source and
> does not need to be in global scope, so make it static.
>
> Cleans up sparse warning:
> symbol '_svc_create_xprt' was n
ly. (Except for that read_u32... return, I
wonder if we're missing a check there.)
--b.
>
> -dros
>
> > On Oct 23, 2017, at 4:31 PM, J. Bruce Fields wrote:
> >
> > In the past we've avoided BUG_ON(X) where X might have side effects, on
> > the theo
On Tue, Oct 24, 2017 at 02:18:52PM -0400, Jeff Layton wrote:
> On Tue, 2017-10-24 at 13:53 -0400, J. Bruce Fields wrote:
> > On Tue, Oct 24, 2017 at 01:26:49PM -0400, Weston Andros Adamson wrote:
> > > Is there a reason to BUG() in these places? Couldn't we WARN_ON_ONCE and
On Tue, Nov 14, 2017 at 07:48:18PM +0300, Vitaly Lipatov wrote:
> for fcntl64 with F_GETLK64 we need use checking against COMPAT_LOFF_T_MAX.
>
> Fixes: 94073ad77fff2 "fs/locks: don't mess with the address limit in
> compat_fcntl64"
>
> Signed-off-by: Vitaly Lipatov
> ---
> fs/fcntl.c | 14
On Mon, Oct 30, 2017 at 04:47:58PM +0300, Vasily Averin wrote:
> nlm_complain_hosts() walk through nlm_server_hosts hlist that should be
> protected by nlm_host_mutex.
I haven't looked at the NLM locking in ages. Do we know who else might
actually be accessing this list concurrently?
--b.
>
>
Please pull an nfsd bugfix for 4.3 from:
git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.3-1
Just this one RDMA fix for now.--b.
Steve Wise (1):
svcrdma: handle rdma read with a non-zero initial page offset
net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 6 --
1 file changed, 4 insert
On Wed, Oct 07, 2015 at 02:39:55PM +0300, Andrey Ryabinin wrote:
> Currently we have reference-counted per-net NSM RPC client
> which created on the first monitor request and destroyed
> after the last unmonitor request. It's needed because
> RPC client need to know 'utsname()->nodename', but utsna
On Tue, Aug 04, 2015 at 01:52:59PM +0200, Andreas Gruenbacher wrote:
> The vfs does not apply the umask for file systems that support acls. The
> test used for this used to be called IS_POSIXACL(). Switch to a new
> IS_ACL() test to check for either posix acls or richacls instead. Add a new
> MS_RI
On Tue, Aug 04, 2015 at 01:53:01PM +0200, Andreas Gruenbacher wrote:
> Normally, deleting a file requires write and execute access to the parent
> directory. With Richacls, a process with MAY_DELETE_SELF access to a file
> may delete the file even without write access to the parent directory.
>
>
On Tue, Aug 04, 2015 at 01:53:08PM +0200, Andreas Gruenbacher wrote:
> A richacl roughly grants a requested access if the NFSv4 acl in the
> richacl grants the requested permissions according to the NFSv4
> permission check algorithm and the file mask that applies to the process
> includes the requ
On Fri, Aug 28, 2015 at 02:36:15PM -0700, Andy Lutomirski wrote:
> On Tue, Aug 4, 2015 at 4:53 AM, Andreas Gruenbacher
> wrote:
> > Normally, deleting a file requires write and execute access to the parent
> > directory. With Richacls, a process with MAY_DELETE_SELF access to a file
> > may delet
On Sat, Aug 29, 2015 at 12:06:22AM +0200, Andreas Grünbacher wrote:
> 2015-08-28 23:49 GMT+02:00 J. Bruce Fields :
> > On Tue, Aug 04, 2015 at 01:53:08PM +0200, Andreas Gruenbacher wrote:
> >> + /*
> >> + * We don't care which class the pro
On Tue, Aug 04, 2015 at 01:53:07PM +0200, Andreas Gruenbacher wrote:
> Doing a chmod() sets the file mode, which includes the file permission
> bits. When a file has a richacl, the permissions that the richacl
> grants need to be limited to what the new file permission bits allow.
>
> This is don
On Mon, Oct 12, 2015 at 10:41:06AM +, Kosuke Tatsukawa wrote:
> J. Bruce Fields wrote:
> > On Fri, Oct 09, 2015 at 06:29:44AM +, Kosuke Tatsukawa wrote:
> >> Neil Brown wrote:
> >> > Kosuke Tatsukawa writes:
> >> >
> >> >> The
Please pull two more nfsd bugfixes for 4.3 from:
git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.3-2
Two nfsd fixes, one for an RDMA crash, one for a pnfs/block protocol
bug.
--b.
Christoph Hellwig (1):
nfsd/blocklayout: accept any minlength
Chuck Lever (1):
svcrdma: Fix NFS s
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
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
> >>
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:
&
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 p
On Tue, Aug 04, 2015 at 01:53:00PM +0200, Andreas Gruenbacher wrote:
> Richacls distinguish between creating non-directories and directories. To
> support that, add an isdir parameter to may_create(). When checking
> inode_permission() for create permission, pass in an additional
> MAY_CREATE_FILE
On Wed, Sep 02, 2015 at 09:06:32PM +0200, Andreas Gruenbacher wrote:
> 2015-09-02 20:53 GMT+02:00 J. Bruce Fields :
> >> @@ -453,7 +453,8 @@ static int sb_permission(struct super_block *sb,
> >> struct inode *inode, int mask)
> >> * this, letting us set arbitr
mode permission bits: they are
> determined by the file masks; see richacl_masks_to_mode().
>
> Signed-off-by: Andreas Gruenbacher
> Reviewed-by: J. Bruce Fields
> ---
> fs/richacl_base.c | 156
>
> include/linux/richacl.h |
extended attribute already includes the file masks.
> >
> > Setting an acl also sets the file mode permission bits: they are
> > determined by the file masks; see richacl_masks_to_mode().
> >
> > Signed-off-by: Andreas Gruenbac
svcrdma: Fix send_reply() scatter/gather set-up
svcrdma: Clean up svc_rdma_get_reply_array()
svcrdma: Remove svc_rdma_fastreg()
svcrdma: Change maximum server payload back to RPCSVC_MAXPAYLOAD
J. Bruce Fields (5):
Revert "Documentation: NFS/RDMA: Document sepa
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
On Thu, Oct 01, 2015 at 07:36:19PM +0300, Andrey Ryabinin wrote:
> On 09/29/2015 09:47 PM, J. Bruce Fields wrote:
> > On Wed, Sep 23, 2015 at 03:49:29PM +0300, Andrey Ryabinin wrote:
> >> Commit cb7323fffa85 ("lockd: create and use per-net NSM
> >> RPC clients on
OK, applied for for-4.19, thanks.--b.
On Wed, Aug 01, 2018 at 07:44:05PM -0500, Gustavo A. R. Silva wrote:
> Return statements in functions returning bool should use true or false
> instead of an integer value.
>
> This issue was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A
On Tue, Aug 07, 2018 at 01:02:16PM +0800, Rong Chen wrote:
>
>
> On 08/01/2018 07:46 PM, J. Bruce Fields wrote:
> > On Fri, Jul 27, 2018 at 08:22:25AM +0800, Ye Xiaolong wrote:
> > > On 07/16, Ye Xiaolong wrote:
> > > > On 07/04, Huang, Ying wrote:
On Wed, Aug 08, 2018 at 12:47:22PM -0400, Jeff Layton wrote:
> On Wed, 2018-08-08 at 11:51 +1000, NeilBrown wrote:
> > If you have a many-core machine, and have many threads all wanting to
> > briefly lock a give file (udev is known to do this), you can get quite
> > poor performance.
> >
> > When
On Wed, Aug 08, 2018 at 06:47:34AM -0400, Jeff Layton wrote:
> On Wed, 2018-08-08 at 11:51 +1000, NeilBrown wrote:
> > struct file lock contains an 'fl_next' pointer which
> > is used to point to the lock that this request is blocked
> > waiting for. So rename it to fl_blocker.
> >
> > The fl_blo
On Wed, Aug 08, 2018 at 11:51:07AM +1000, NeilBrown wrote:
> If you have a many-core machine, and have many threads all wanting to
> briefly lock a give file (udev is known to do this), you can get quite
> poor performance.
>
> When one thread releases a lock, it wakes up all other threads that
>
On Wed, Aug 08, 2018 at 03:54:45PM -0400, J. Bruce Fields wrote:
> On Wed, Aug 08, 2018 at 11:51:07AM +1000, NeilBrown wrote:
> > If you have a many-core machine, and have many threads all wanting to
> > briefly lock a give file (udev is known to do this), you can get quite
>
On Wed, Aug 08, 2018 at 04:09:12PM -0400, J. Bruce Fields wrote:
> On Wed, Aug 08, 2018 at 03:54:45PM -0400, J. Bruce Fields wrote:
> > On Wed, Aug 08, 2018 at 11:51:07AM +1000, NeilBrown wrote:
> > > If you have a many-core machine, and have many threads all wanting to
> &g
On Wed, Aug 08, 2018 at 06:50:06PM -0400, Jeff Layton wrote:
> That seems like a legit problem.
>
> One possible fix might be to have the waiter on (1,2) walk down the
> entire subtree and wake up any waiter that is waiting on a lock that
> doesn't conflict with the lock on which it's waiting.
>
On Thu, Aug 09, 2018 at 12:04:41PM +1000, NeilBrown wrote:
> In a future patch we will need to differentiate between conflicts that
> are "transitive" and those that aren't.
> A "transitive" conflict is defined as one where any lock that
> conflicts with the first (newly requested) lock would confl
On Thu, Aug 09, 2018 at 12:04:41PM +1000, NeilBrown wrote:
> When we find an existing lock which conflicts with a request,
> and the request wants to wait, we currently add the request
> to a list. When the lock is removed, the whole list is woken.
> This can cause the thundering-herd problem.
> T
I think there's also a problem with multiple tasks sharing the same
lock owner.
So, all locks are exclusive locks for the same range. We have four
tasks. Tasks 1 and 4 share the same owner, the others' owners are
distinct.
- Task 1 gets a lock.
- Task 2 gets a conflicting lock.
On Fri, Aug 10, 2018 at 08:12:43AM +1000, NeilBrown wrote:
> On Thu, Aug 09 2018, J. Bruce Fields wrote:
>
> > I think there's also a problem with multiple tasks sharing the same
> > lock owner.
> >
> > So, all locks are exclusive locks for the same range. We
On Fri, Aug 10, 2018 at 08:19:26AM +1000, NeilBrown wrote:
> On Thu, Aug 09 2018, J. Bruce Fields wrote:
> > I think you could simplify the code a lot by maintaining the tree so
> > that it always satisfies the condition that waiters are always strictly
> > "weaker"
On Fri, Aug 10, 2018 at 09:40:35AM +1000, NeilBrown wrote:
> caller_fl is first and sys_fl is second.
>
> if sys_fl, the second, is a read lock, and caller_fl, the first, is a
> write lock, they clearly conflict but any other lock that conflict
> with caller_fl (The write lock) would *not* necessa
On Fri, Aug 10, 2018 at 09:56:07AM +1000, NeilBrown wrote:
> On Thu, Aug 09 2018, J. Bruce Fields wrote:
> > If we only cared about the former, and only in simple cases, we could
> > walk the entire list and skip waking up only the locks that conflict
> > with the first one
On Fri, Aug 10, 2018 at 11:50:58AM +1000, NeilBrown wrote:
> You're good at this game!
Everybody's got to have a hobby, mine is pathological posix locking
cases
> So, because a locker with the same "owner" gets a free pass, you can
> *never* say that any lock which conflicts with A also confl
On Fri, Aug 10, 2018 at 01:17:14PM +1000, NeilBrown wrote:
> On Thu, Aug 09 2018, J. Bruce Fields wrote:
>
> > On Fri, Aug 10, 2018 at 11:50:58AM +1000, NeilBrown wrote:
> >> You're good at this game!
> >
> > Everybody's got to have a hobby, m
On Sat, Aug 11, 2018 at 07:51:13AM -0400, Jeff Layton wrote:
> On Thu, 2018-08-09 at 20:29 -0400, J. Bruce Fields wrote:
> > On Fri, Aug 10, 2018 at 08:12:43AM +1000, NeilBrown wrote:
> > > On Thu, Aug 09 2018, J. Bruce Fields wrote:
> > >
> > > > I thi
On Sat, Aug 11, 2018 at 07:56:25AM -0400, Jeff Layton wrote:
> FWIW, I did a bit of testing with lockperf tests that I had written on
> an earlier rework of this code:
>
> https://git.samba.org/jlayton/linux.git/?p=jlayton/lockperf.git;a=summary
>
>
> The posix01 and flock01 tests in there s
Biggers (1):
nfsd: constify write_op[]
Gustavo A. R. Silva (2):
nfsd: Mark expected switch fall-through
nfsd: use true and false for boolean values
J. Bruce Fields (9):
nfsd4: extend reclaim period for reclaiming clients
nfsd4: return default lease period
nfsd:
Apologies, I messed up my pull request. The result was just a few
commits mentioned in the tag description but missing from the tip of the
branch, and I thought simplest was to make a new tag and a new pull
request with the additional commits, I hope that works OK. Thanks to
Chuck for noticing th
On Fri, Jul 27, 2018 at 08:22:25AM +0800, Ye Xiaolong wrote:
> On 07/16, Ye Xiaolong wrote:
> >On 07/04, Huang, Ying wrote:
> >>"J. Bruce Fields" writes:
> >>
> >>> Thanks!
> >>>
> >>> On Wed, Jun 20, 2018 at 02:52:43PM +080
On Tue, Jul 31, 2018 at 09:24:10PM -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
Thanks, applying for 2.19.
--b.
>
> Warning level 2 was used: -Wimplicit-fallthrough=2
>
> Signed-off-by: Gustavo
On Mon, Jul 23, 2018 at 09:57:11AM +0800, nixiaoming wrote:
> READ_BUF(8);
> dummy = be32_to_cpup(p++);
> dummy = be32_to_cpup(p++);
> ...
> READ_BUF(4);
> dummy = be32_to_cpup(p++);
>
> Assigning value to "dummy" here, but that stored value
> is overwritten before it can be used.
> At the same ti
On Thu, Aug 02, 2018 at 01:00:26PM +, Nixiaoming wrote:
> On Wednesday, August 01, 2018 11:18 PM , J. Bruce Fields wrote:
> >On Mon, Jul 23, 2018 at 09:57:11AM +0800, nixiaoming wrote:
> >> READ_BUF(8);
> >> dummy = be32_to_cpup(p++);
> >> dummy = be32_to
Thanks, applied.--b.
On Mon, Jan 22, 2018 at 10:09:12PM +0100, Arnd Bergmann wrote:
> There is now only one caller left for svcxdr_dupstr() and this is inside
> of an #ifdef, so we can get a warning when the option is disabled:
>
> fs/nfsd/nfs4xdr.c:241:1: error: 'svcxdr_dupstr' defined but not u
On Wed, Dec 27, 2017 at 12:10:15PM +, Reshetova, Elena wrote:
> > On Fri, Dec 22, 2017 at 09:25:53AM -0500, J. Bruce Fields wrote:
> > > On Fri, Dec 22, 2017 at 09:29:15AM +, Reshetova, Elena wrote:
> > > >
> > > > On Wed, Nov 29, 2017 at
o ensure the stateid invalidation is also recognised by the "existing lock"
> path, and also by a second call to nfsd4_free_lock_stateid() itself, we can
> change the type to NFS4_CLOSED_STID under the stp->st_mutex.
>
> Signed-off-by: Trond Myklebust
> Signed-off-b
d invalidation is also recognised by the "existing lock"
> path, and also by a second call to nfsd4_free_lock_stateid() itself, we can
> change the type to NFS4_CLOSED_STID under the stp->st_mutex.
>
> Signed-off-by: Trond Myklebust
> Signed-off-by: J. Bruce Fie
and also by a second call to nfsd4_free_lock_stateid() itself, we can
> change the type to NFS4_CLOSED_STID under the stp->st_mutex.
>
> Signed-off-by: Trond Myklebust
> Signed-off-by: J. Bruce Fields
> Signed-off-by: Sasha Levin
> ---
> fs/nfsd/nfs4state.c | 19 --
On Tue, Jan 23, 2018 at 07:47:31PM -0500, Trond Myklebust wrote:
> Sorry I forgot about the issues with the server garbage collector, and
> I applied these patches to my linux-next a couple of weeks ago.
Whoops, OK, so who's taking those patches anyway?
> What say we fix the issue with something
On Wed, Apr 05, 2017 at 02:14:09PM -0400, J. Bruce Fields wrote:
> On Wed, Apr 05, 2017 at 10:05:51AM +0200, Jan Kara wrote:
> > 1) Keep i_version as is, make clients also check for i_ctime.
>
> That would be a protocol revision, which we'd definitely rather avoid.
>
&g
On Fri, May 12, 2017 at 10:27:54AM +0200, Jan Kara wrote:
> On Thu 11-05-17 14:59:43, J. Bruce Fields wrote:
> > On Wed, Apr 05, 2017 at 02:14:09PM -0400, J. Bruce Fields wrote:
> > > On Wed, Apr 05, 2017 at 10:05:51AM +0200, Jan Kara wrote:
> > > > 1) Keep i_version
On Fri, May 12, 2017 at 07:01:25AM -0400, Jeff Layton wrote:
> This looks reasonable to me (modulo Jan's comment about casting tv_sec
> to u64).
>
> To be clear, I think this is mostly orthogonal to the changes that I was
> originally proposing, right? I think we can still benefit from only
> bump
On Fri, May 12, 2017 at 08:22:23AM +1000, NeilBrown wrote:
> On Thu, May 11 2017, J. Bruce Fields wrote:
> > +static inline u64 nfsd4_change_attribute(struct inode *inode)
> > +{
> > + u64 chattr;
> > +
> > + chattr = inode->i_ctime.tv_sec << 30
On Tue, Jan 09, 2018 at 09:10:41AM -0500, Jeff Layton wrote:
> --- /dev/null
> +++ b/include/linux/iversion.h
> @@ -0,0 +1,236 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_IVERSION_H
> +#define _LINUX_IVERSION_H
> +
> +#include
> +
> +/*
> + * The change attribute (i_version) is
On Tue, Jan 09, 2018 at 09:10:42AM -0500, Jeff Layton wrote:
> From: Jeff Layton
>
> The rationale for taking the i_lock when incrementing this value is
> lost in antiquity. The readers of the field don't take it (at least
> not universally), so my assumption is that it was only done here to
> se
On Fri, Jan 19, 2018 at 09:36:34AM -0500, Jeff Layton wrote:
> Shrug...we have that problem with the spinlock in place too. The bottom
> line is that reads of this value are not serialized with the increment
> at all.
OK, so this wouldn't even be a new bug.
> I'm not 100% thrilled with this patch
On Fri, Jan 19, 2018 at 10:58:27PM +0100, Rasmus Villemoes wrote:
> On 2018-01-19 15:54, Arnd Bergmann wrote:
> > There is now only one caller left for svcxdr_dupstr() and this is inside
> > of an #ifdef, so we can get a warning when the option is disabled:
> >
> > fs/nfsd/nfs4xdr.c:241:1: error:
On Mon, Jan 01, 2018 at 02:18:55AM -0800, Matthew Wilcox wrote:
> On Sat, Dec 30, 2017 at 06:00:57PM -0500, Theodore Ts'o wrote:
> > On Sat, Dec 30, 2017 at 05:40:28PM -0500, Theodore Ts'o wrote:
> > > On Sat, Dec 30, 2017 at 12:44:17PM -0800, Matthew Wilcox wrote:
> > > >
> > > > I'm not sure I a
On Fri, Jan 05, 2018 at 11:49:41AM -0500, bfields wrote:
> On Mon, Jan 01, 2018 at 02:18:55AM -0800, Matthew Wilcox wrote:
> > On Sat, Dec 30, 2017 at 06:00:57PM -0500, Theodore Ts'o wrote:
> > > On Sat, Dec 30, 2017 at 05:40:28PM -0500, Theodore Ts'o wrote:
> > > > On Sat, Dec 30, 2017 at 12:44:17
Looks right to me.
Reviewed-by: J. Bruce Fields
--b.
On Mon, Jan 15, 2018 at 06:30:46PM +0100, Max Kellermann wrote:
> Make IS_POSIXACL() return false if POSIX ACL support is disabled and
> ignore SB_POSIXACL/MS_POSIXACL.
>
> Never skip applying the umask in namei.c and never both
Please pull an nfsd bugfix from:
git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.16-1
Just one fix for an occasional panic from Jeff Layton.
--b.
Jeff Layton (1):
nfsd: remove blocked locks on client teardown
fs/nfsd/
Applying, thanks!--b.
On Mon, Mar 19, 2018 at 11:37:05PM +0100, Stefan Agner wrote:
> Use enum nfs_cb_opnum4 in decode_cb_op_status. This fixes warnings
> seen with clang:
> fs/nfsd/nfs4callback.c:451:36: warning: implicit conversion from
> enumeration type 'enum nfs_cb_opnum4' to differen
either, so the stakes are low, I'm mainly just curious.)
--b.
On Mon, Apr 09, 2018 at 12:19:02AM +0000, Sasha Levin wrote:
> From: "J. Bruce Fields"
>
> [ Upstream commit 0078117c6d9160031b866cfa1853514d4f6865d2 ]
>
> A client that sends more than a hundred op
On Fri, Nov 23, 2018 at 03:56:33PM +0800, Pan Bian wrote:
> The function dentry_connected calls dput(dentry) to drop the previously
> acquired reference to dentry. In this case, dentry can be released.
> After that, IS_ROOT(dentry) checks the condition
> (dentry == dentry->d_parent), which may resu
Thanks for the report!
On Tue, Nov 27, 2018 at 02:01:02PM +0800, kernel test robot wrote:
> FYI, we noticed a -62.5% regression of will-it-scale.per_thread_ops due to
> commit:
>
>
> commit: 83b381078b5ecab098ebf6bc9548bb32af1dbf31 ("fs/locks: always
> delete_block after waiting.")
> https://g
what a lot of the other nfsctl
methods do.
--b.
commit ad5fdf47b4e3
Author: J. Bruce Fields
Date: Tue Nov 27 15:54:17 2018 -0500
nfsd4: fix crash on writing v4_end_grace before nfsd startup
Anatoly Trosinenko reports that this:
1) Checkout fresh master Linux branch (test
Thanks, applying for 4.21.--b.
On Sat, Nov 03, 2018 at 04:12:53PM +, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to clean up indentation, add in missing tabs.
>
> Signed-off-by: Colin Ian King
> ---
> fs/nfsd/nfs4state.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deleti
On Tue, Nov 27, 2018 at 03:58:49PM -0500, J. Bruce Fields wrote:
> On Sun, Nov 25, 2018 at 09:17:10AM +0300, Anatoly Trosinenko wrote:
> > When manually exploring the kernel NFSd feature, I have stumbled upon
> > a NULL-dereference when writing to v4_end_grace when server is not
On Mon, Nov 12, 2018 at 12:14:48PM +1100, NeilBrown wrote:
> struct file lock contains an 'fl_next' pointer which
> is used to point to the lock that this request is blocked
> waiting for. So rename it to fl_blocker.
>
> The fl_blocked list_head in an active lock is the head of a list of
> blocke
On Mon, Nov 12, 2018 at 12:14:49PM +1100, NeilBrown wrote:
> When we find an existing lock which conflicts with a request,
> and the request wants to wait, we currently add the request
> to a list. When the lock is removed, the whole list is woken.
> This can cause the thundering-herd problem.
> T
ACK to the series.
It also passed my usual regression tests on top of 4.19. (I still have
some unrelated problems to sort out on 4.20.)
--b.
On Mon, Nov 12, 2018 at 12:14:48PM +1100, NeilBrown wrote:
> Changes:
> - field names improved as requested by Bruce.
>"fl_blocked_requests" is a lis
Please pull:
git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.20-1
Three nfsd bugfixes. None are new bugs, but they all take a little
effort to hit, which might explain why they weren't found sooner.
--b.
Frank Sorenson (1):
sunrpc: correct the computation for page_ptr when truncatin
On Mon, Dec 03, 2018 at 11:30:30AM +1100, NeilBrown wrote:
> This is the same series as posted on 07 November, modified slightly
> to match some recent code changes upstream - nothing substantial.
>
> General description:
>
> There doesn't seem to be a maintainer for the 'cred' code, so I don't
>
On Fri, Nov 09, 2018 at 11:38:19AM +1100, NeilBrown wrote:
> On Thu, Nov 08 2018, J. Bruce Fields wrote:
>
> > On Mon, Nov 05, 2018 at 12:30:48PM +1100, NeilBrown wrote:
> >> When we find an existing lock which conflicts with a request,
> >> and the request wants
On Fri, Nov 09, 2018 at 11:32:16AM +1100, NeilBrown wrote:
> On Thu, Nov 08 2018, J. Bruce Fields wrote:
>
> > On Mon, Nov 05, 2018 at 12:30:47PM +1100, NeilBrown wrote:
> >> struct file lock contains an 'fl_next' pointer which
> >> is used to point
On Fri, Nov 09, 2018 at 05:24:04PM +1100, NeilBrown wrote:
> Thanks pretty thorough - and even looks correct.
> I'll re-reading some time when it isn't late, and maybe make it into a
> comment in the code.
> I agree, this sort of documentation can be quite helpful.
OK. The idea looks sound to me,
This version looks correct to me, and simpler. I'll be curious to hear
whatever you learn from testing!
--b.
On Tue, Aug 14, 2018 at 01:56:51PM +1000, NeilBrown wrote:
>
> V2, which added wake_non_conflicts() was more broken than V1 - as
> Bruce explained there is no transitivity in the blockin
On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813
> git tree: linux-next
I fetched linux-next but don't have 5ed5da74de9e.
I'm also not sure why I'm
On Wed, Aug 15, 2018 at 10:11:20AM +1000, Stephen Rothwell wrote:
> Hi Bruce,
>
> On Tue, 14 Aug 2018 13:50:20 -0700 Dmitry Vyukov wrote:
> >
> > On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
> > wrote:
> > > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syz
On Tue, Aug 14, 2018 at 01:50:20PM -0700, Dmitry Vyukov wrote:
> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
> wrote:
> > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
> >> syzbot has found a reproducer for the following crash on:
> >>
> >>
On Fri, Aug 17, 2018 at 01:22:31PM -0500, Eric W. Biederman wrote:
> Dmitry Vyukov writes:
>
> > On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
> > wrote:
> >> Dmitry Vyukov writes:
> >>
> >>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fiel
On Sat, Aug 18, 2018 at 12:51:14AM -0500, Eric W. Biederman wrote:
> I was dismayed when I saw the syzbot report triggered someone to remove
> themselves from MAINTAINERS.
You're talking about my patch? I think you misread it, I'm not removing
myself from MAINTAINERS.
--b.
601 - 700 of 1455 matches
Mail list logo
