On Thu, Jun 27, 2019 at 06:30:27PM +, 黄乐 wrote:
> from: Huang Le
>
> In move_to_close_lru(), which only be called on path of nfsd4 CLOSE op,
> the code could wait for its stid ref count drop to 2 while holding its
> state owner replay mutex. However, the other stid ref holder (normally
> a p
On Tue, Dec 04, 2018 at 09:33:18PM +, Schumaker, Anna wrote:
> On Tue, 2018-12-04 at 15:21 -0500, J. Bruce Fields wrote:
> > 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 chang
On Tue, Apr 17, 2018 at 09:54:36PM +, Trond Myklebust wrote:
> Yes, and we can probably convert it, and the other GFP_ATOMIC
> allocations in the rpcbind client to use GFP_NOFS in order to improve
> reliability.
Chuck, I think the GFP_ATOMIC is unnecessary here as well?
--b.
diff --git a/net
From: "J. Bruce Fields"
Date: Tue, 8 May 2018 11:47:03 -0400
Subject: [PATCH 2/2] sunrpc: convert unnecessary GFP_ATOMIC to GFP_NOFS
It's OK to sleep here, we just don't want to recurse into the filesystem
as this writeout could be waiting on this.
As a next step: the documentation for GFP_NOFS
From: "J. Bruce Fields"
If we ignore the error we'll hit a null dereference a little later.
Reported-by: syzbot+4b98281f2401ab849...@syzkaller.appspotmail.com
Signed-off-by: J. Bruce Fields
---
net/sunrpc/rpcb_clnt.c | 8
1 file changed, 8 insertions(+)
diff --git a/net/sunrpc/rpcb_c
On Sat, Feb 10, 2018 at 01:41:55AM +, Trond Myklebust wrote:
> On Fri, 2018-02-09 at 23:06 -0200, Thiago Rafael Becker wrote:
> > When investigating reasons for nfs failures, packet dumps arei
> > eventually used.
> > Finding the rpc that generated the failure is done by comparing all
> > sent
Please pull:
git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.13-1
One fix for a problem introduced in the most recent merge window and
found by Dave Jones and KASAN.
--b.
Trond Myklebust (1):
nfsd: Fix a memory scribble in the callback channel
fs/nfsd/nfs4callback.c | 6 +++---
1 f
On Wed, Sep 16, 2015 at 01:18:29PM -0400, Jeff Layton wrote:
> On Mon, 14 Sep 2015 12:10:15 -0400
> "bfie...@fieldses.org" wrote:
>
> > On Sat, Sep 12, 2015 at 06:24:54AM -0400, Jeff Layton wrote:
> > > I don't think it matters, at least not on x86_64. bo
On Sat, Sep 12, 2015 at 06:24:54AM -0400, Jeff Layton wrote:
> On Sat, 12 Sep 2015 04:41:33 +
> "Dilger, Andreas" wrote:
>
> > On 2015/09/11, 4:20 AM, "HPDD-discuss on behalf of Jeff Layton"
> >
> > wrote:
> >
> > >With NFSv3 nfsd will always attempt to send along WCC data to the
> > >clien
On Thu, Apr 25, 2013 at 02:51:20PM -0400, Chuck Lever wrote:
>
> On Apr 25, 2013, at 2:46 PM, "bfie...@fieldses.org"
> wrote:
>
> > On Thu, Apr 25, 2013 at 02:40:11PM -0400, Chuck Lever wrote:
> >>
> >> On Apr 25, 2013, at 2:19 PM, "bfie...@
On Thu, Apr 25, 2013 at 02:40:11PM -0400, Chuck Lever wrote:
>
> On Apr 25, 2013, at 2:19 PM, "bfie...@fieldses.org"
> wrote:
>
> > On Thu, Apr 25, 2013 at 02:10:36PM +, Myklebust, Trond wrote:
> >> On Thu, 2013-04-25 at 09:49 -0400, bfie...@fieldses.
On Thu, Apr 25, 2013 at 02:10:36PM +, Myklebust, Trond wrote:
> On Thu, 2013-04-25 at 09:49 -0400, bfie...@fieldses.org wrote:
> > On Thu, Apr 25, 2013 at 01:30:58PM +, Myklebust, Trond wrote:
> > > On Thu, 2013-04-25 at 09:29 -0400, bfie...@fieldses.org wrote:
> >
On Thu, Apr 25, 2013 at 01:30:58PM +, Myklebust, Trond wrote:
> On Thu, 2013-04-25 at 09:29 -0400, bfie...@fieldses.org wrote:
>
> > My position is that we simply have no idea what order of magnitude even
> > delay should be. And that in such a situation exponential b
On Thu, Apr 25, 2013 at 08:19:34AM -0400, David Wysochanski wrote:
> On Wed, 2013-04-24 at 22:35 +, Myklebust, Trond wrote:
> > On Wed, 2013-04-24 at 16:54 -0500, Dave Chiluk wrote:
> > > On 04/24/2013 04:28 PM, Myklebust, Trond wrote:
> > > > On Wed, 2013-04-24 at 15:55 -0500, Dave Chiluk wrot
On Tue, Oct 09, 2012 at 02:13:30PM +, Myklebust, Trond wrote:
> On Tue, 2012-10-09 at 14:30 +0100, David Howells wrote:
> > Can you merge the following branch into the nfs tree please.
> >
> > This is to complete part of the Userspace API (UAPI) disintegration for
> > which
> > the preparator
On Mon, Jul 30, 2012 at 11:12:05PM +, Myklebust, Trond wrote:
> On Fri, 2012-07-20 at 15:57 +0400, Stanislav Kinsbursky wrote:
> > Without this patch kernel will panic on LockD start, because lockd_up()
> > checks
> > lockd_up_net() result for negative value.
> > >From my pow it's better to re
16 matches
Mail list logo
