lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CABVgOSkHoVcRQLGVTZZ1andSY4UHqoRwLdyiTHh9KTQ4m3av9w@mail.gmail.com>
Date:   Sat, 11 Sep 2021 06:21:16 +0800
From:   David Gow <davidgow@...gle.com>
To:     Arthur Marsh <arthur.marsh@...ernode.on.net>
Cc:     Shuah Khan <skhan@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>
Subject: Re: After KUnit update for Linux 5.15-rc1 - unable to share VFAT
 filesystem via samba

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ