On Fri, Sep 10, 2021 at 8:02 PM Arthur Marsh <arthur.marsh@xxxxxxxxxxxxxxxx> wrote: > > > Hi, I have been sharing an old VFAT formatted hard disk on one pc to > another using Samba and sometime after kernel 5.14.0 it stopped working (apparently no longer being shared as the mount.smbfs command > on the client failed with error -13 yet mount.smbfs still worked for > ext3 filesytems shared from the same machine which had the VFAT > filesystem). > The only error I saw on the machine with the VFAT formatted hard disk > was the output of the mount command had truncated the name of the > mount to only include the first 4 characters of the base name of the > mount point. > e.g. when VFAT filesystem was mounted on /mnt/victoria, the output of > the mount command showed the filesytem mounted on /mnt/vict > I can't reproduce this on my machine (which is openSUSE Tumbleweed with their "vanilla" 5.14 kernel package on x86_64, mounting a FAT16 filesystem). # mount /dev/sda1 /mnt/victoria # mount | grep vic /dev/sda1 on /mnt/victoria type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) # uname -a Linux patpat 5.14.0-1-vanilla #1 SMP Mon Aug 30 07:01:36 UTC 2021 (dc06e24) x86_64 x86_64 x86_64 GNU/Linux I can try it again on an older i386 machine, but I doubt that'd change things: this doesn't smell architecture-specific to me. This seems a lot more like it's something to do with /proc/mounts or similar, rather than a FAT specific issue (and, unless something really strange has happened with the CONFIG_FAT_DEFAULT_CODEPAGE config option, which I doubt), this change shouldn't affect anything at all when KUnit isn't enabled and used. I suspect it just shows up in the bisect because it's basically the only change in fs/fat for a while. The bisect against the whole kernel tree seems likely to be of more use. -- David