Re: After KUnit update for Linux 5.15-rc1 - unable to share VFAT filesystem via samba

[David Gow]

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