Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1697063 > unrolled thread

[REGRESSION 4.13-rc] NFS returns -EACCESS at the first read

Started byTakashi Iwai <tiwai@suse.de>
First post2017-07-26 15:00 +0200
Last post2017-07-26 15:40 +0200
Articles 4 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [REGRESSION 4.13-rc] NFS returns -EACCESS at the first read Takashi Iwai <tiwai@suse.de> - 2017-07-26 15:00 +0200
    Re: [REGRESSION 4.13-rc] NFS returns -EACCESS at the first read Anna Schumaker <schumaker.anna@gmail.com> - 2017-07-26 15:00 +0200
      Re: [REGRESSION 4.13-rc] NFS returns -EACCESS at the first read Takashi Iwai <tiwai@suse.de> - 2017-07-26 15:40 +0200
        Re: [REGRESSION 4.13-rc] NFS returns -EACCESS at the first read Anna Schumaker <schumaker.anna@gmail.com> - 2017-07-26 15:40 +0200

#1697063 — [REGRESSION 4.13-rc] NFS returns -EACCESS at the first read

FromTakashi Iwai <tiwai@suse.de>
Date2017-07-26 15:00 +0200
Subject[REGRESSION 4.13-rc] NFS returns -EACCESS at the first read
Message-ID<u7u4V-qb-1@gated-at.bofh.it>
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?


thanks,

Takashi

[toc] | [next] | [standalone]


#1697067

FromAnna Schumaker <schumaker.anna@gmail.com>
Date2017-07-26 15:00 +0200
Message-ID<u7u4V-qb-11@gated-at.bofh.it>
In reply to#1697063
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,
Anna
> 
> 
> thanks,
> 
> Takashi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[toc] | [prev] | [next] | [standalone]


#1697091

FromTakashi Iwai <tiwai@suse.de>
Date2017-07-26 15:40 +0200
Message-ID<u7uHD-SQ-13@gated-at.bofh.it>
In reply to#1697067
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@suse.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

[toc] | [prev] | [next] | [standalone]


#1697110

FromAnna Schumaker <schumaker.anna@gmail.com>
Date2017-07-26 15:40 +0200
Message-ID<u7uHF-SQ-55@gated-at.bofh.it>
In reply to#1697091

On 07/26/2017 09:30 AM, Takashi Iwai wrote:
> 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@suse.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?

I just started looking at that at the end of the day yesterday.  I think they work by accident, since all the bits in the mask are set by nfs_do_access().  They should probably be converted, but I don't think it's urgent.

Anna

> 
> 
> thanks,
> 
> Takashi
> 

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web