Re: AW: regression in CIFS(?) between 4.17.14 and 4.18.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



чт, 20 сент. 2018 г. в 5:10, Dr. Bernd Feige
<bernd.feige@xxxxxxxxxxxxxxxxxxxxx>:
>
> Dear Aurélien et al.,
>
> > so here are the dmesg logs and Stats with 4.17.19. With this kernel
> > version no hangs occur.
> >
> > I listed the directory three times and append the additional dmesg
> > entries after each listing.
> >
> > Note that I also checked 4.18.9 as there have been some cifs patches
> > in
> > 4.18.8 and one in 4.18.9. Same hangs with this newer version.
>
> After some time on 4.17.19, red dmesg messages appeared saying:
>
> CIFS VFS: Autodisabling the use of server inode numbers on
> \\fsgroup4\group. This server doesn't seem to support them properly.
> Hardlinks will not be recognized on this mount. Consider mounting with
> the "noserverino" option to silence this message.
>
> This message was not seen in the logs while I was doing the tests.
>
> So I tried whether adding "noserverino" to the mount options makes a
> difference for 4.18.9, and really, didn't experience a hang since. I
> guess that disabling Unix Extensions would have the same effect.
> I didn't specifically enable Unix Extensions though and feel that
> 4.17.19 handled the situation much more gracefully than 4.18 in this
> probably relatively common corporate situation with Microsoft servers.
>
> Thanks and best regards,
> Bernd

Thanks for the info.

cifs_revalidate_dentry_attr fails with ESTALE error code for both
kernels, v4.17 does cifs_lookup right after getting ESTALE previously
but v4.18 doesn't do that. Probably there are some VFS changes that
affects the behavior.

Since we know that inode number uniqueness is not guaranteed for DFS,
shouldn't we just skip the following check

 911 >--->---/* if uniqueid is different, return error */
 912 >--->---if (unlikely(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SERVER_INUM &&
 913 >--->---    CIFS_I(*inode)->uniqueid != fattr.cf_uniqueid)) {
 914 >--->--->---rc = -ESTALE;
 915 >--->--->---goto cgii_exit;
 916 >--->---}

by adding extra check for !(fattr->cf_flags & CIFS_FATTR_DFS_REFERRAL)?

--
Best regards,
Pavel Shilovsky




[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux