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]

Date:   Tue, 6 Mar 2018 12:07:58 -0800
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Dave Chinner <david@...morbit.com>
Cc:     Eric Sandeen <sandeen@...hat.com>, linux-ext4@...r.kernel.org,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>
Subject: Re: ext4 confusion

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.

thanks,

-- 
~Randy