Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <6A72EAE4-A0F7-4CD2-89BB-36A8F4A7D321@internode.on.net>
In-Reply-To: <6A72EAE4-A0F7-4CD2-89BB-36A8F4A7D321@internode.on.net>
From:   David Gow <davidgow@google.com>
Date:   Sat, 11 Sep 2021 06:21:16 +0800
Message-ID: <CABVgOSkHoVcRQLGVTZZ1andSY4UHqoRwLdyiTHh9KTQ4m3av9w@mail.gmail.com>
Subject: Re: After KUnit update for Linux 5.15-rc1 - unable to share VFAT
 filesystem via samba
To:     Arthur Marsh <arthur.marsh@internode.on.net>
Cc:     Shuah Khan <skhan@linuxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Brendan Higgins <brendanhiggins@google.com>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Sep 10, 2021 at 8:02 PM Arthur Marsh
<arthur.marsh@internode.on.net> 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