[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hzibrjpge.wl-tiwai@suse.de>
Date:   Wed, 26 Jul 2017 15:30:09 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     Anna Schumaker <schumaker.anna@...il.com>
Cc:     Trond Myklebust <trond.myklebust@...marydata.com>,
        Anna Schumaker <anna.schumaker@...app.com>,
        linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [REGRESSION 4.13-rc] NFS returns -EACCESS at the first read
On Wed, 26 Jul 2017 14:57:07 +0200,
Anna Schumaker wrote:
> 
> Hi Takashi,
> 
> On 07/26/2017 08:54 AM, Takashi Iwai wrote:
> > Hi,
> > 
> > I seem hitting a regression of NFS client on the today's Linus git
> > tree.  The symptom is that the file read over NFS returns occasionally
> > -EACCESS at the first read.  When I try to read the same file again
> > (or do some other thing), I can read it successfully.
> > 
> > The git bisection leaded to the commit
> > bd8b2441742b49c76bec707757bd9c028ea9838e
> >     NFS: Store the raw NFS access mask in the inode's access cache
> > 
> > 
> > Any further hint for debugging?
> 
> Does the patch in this email thread help? http://www.spinics.net/lists/linux-nfs/msg64930.html
Thanks, I gave it a shot and the result looks good.  Feel free to my
tested-by tag:
  Tested-by: Takashi Iwai <tiwai@...e.de>
Though, when I look around the code, I feel somehow uneasy by that
still MAY_XXX is used for nfs_access_entry.mask, e.g. in
nfs3_proc_access() or nfs4_proc_access().  Are these function OK
without the similar conversion?
thanks,
Takashi
Powered by blists - more mailing lists
 
