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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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 <[email protected]>
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
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 <[email protected]>
>
>
> 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
>