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