linux-ext4 - Re: ext4 confusion

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4a159529-eb30-bccc-a865-9c6577018c11@redhat.com>
Date:   Tue, 6 Mar 2018 16:53:59 -0600
From:   Eric Sandeen <sandeen@...hat.com>
To:     Randy Dunlap <rdunlap@...radead.org>,
        Dave Chinner <david@...morbit.com>
Cc:     linux-ext4@...r.kernel.org,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>
Subject: Re: ext4 confusion

On 3/6/18 2:07 PM, Randy Dunlap wrote:
> On 03/05/2018 10:47 PM, Dave Chinner wrote:
>> On Mon, Mar 05, 2018 at 09:12:03PM -0800, Randy Dunlap wrote:
>>> On 03/05/2018 08:45 PM, Eric Sandeen wrote:
>>>> On 3/5/18 10:42 PM, Randy Dunlap wrote:
>>>>>>> It's a new OS/installer.  OpenSUSE Tumbleweed, which is their bleeding edge
>>>>>>> rolling updates release.
>>>>>> Hrmph.  A lot of things go into this behavior, it may not be a kernel change at
>>>>>> all that has made it show up now...
>>>>> Yes, it could be that wonderful systemd or something else.
>>>>
>>>> I think I'd pursue a parallel track of bugging SUSE about the issue... ;)
>>>>
>>>> (I don't think the kernel will ever just downgrade an rw mount request to
>>>> ro, or skip an ro->rw transition silently... leaving it ro does seem
>>>> like an init bug, but *shrug* init long ago transitioned into deep magic.)
>>>
>>> More info:  :(
>>>
>>> This problem happens when booting my own custom 4.16-rc3 kernel.
>>> If I boot the OpenSUSE-supplied (4.15.7) kernel, the / fs is remounted rw later on.
>>>
>>> So I'm more or less back to "what am I doing wrong"?
>>
>> The filesystem probing order has probably changed. mount tries to
>> use blkid to determine the filesytem type to use, and if that
>> doesn't find a known type it will fall back to trying mounts with
>> explicit types as per the filesystem type order listed in
>> /proc/filesystems. (it's in the man mount page) Maybe the device
>> module hasn't been loaded when blkid runs to probe existing block
>> devices?
>>
>> These sorts of whacky behaviours have occurred for me in the past
>> when either userspace behaviour changed, the order of filesystems
>> listed in /proc/filesystems or module load order changed. Typically
>> it's a difference in kernel config that causes such shenanigans.
> 
> There is also a (big) difference in the $DISTRO using initramfs and my
> custom kernel not using one. But in both cases the SATA/AHCI driver is
> loaded/ready before ext4fs, so it's still a mystery to me.
> 
> Eric, I tested your patch but it didn't help in my environment.

Odd.  It's supposed to be silent if ext3 doesn't recognize the features,
but ext4 does.  Too many moving parts.  :/

-Eric