linux-ext4 - [Bug 207635] EXT4-fs error (device sda3): ext4_lookup:1701: inode #...: comm find: casefold flag without casefold feature; EXT4-fs (sda3): Remounting filesystem read-only

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:   Mon, 11 May 2020 16:30:42 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...r.kernel.org
Subject: [Bug 207635] EXT4-fs error (device sda3): ext4_lookup:1701: inode
 #...: comm find: casefold flag without casefold feature; EXT4-fs (sda3):
 Remounting filesystem read-only

https://bugzilla.kernel.org/show_bug.cgi?id=207635

--- Comment #5 from Joerg M. Sigle (joerg.sigle@...gle.com) ---
Eric, re. your other question:

>I'm not sure there's anything else to do here, unless we were to make the
>kernel ignore unexpected flags.
>Ted, have you considered that?  And it is intentional that e2fsck ignores
>unknown flags?

Please allow me some input on this:

Someone might use a kernel with casefold or encryption support on Monday - and
even use these features, causing a few of these flags to be set.

The same person might run a kernel with casefold and/or encryption disabled on
Tuesday. So, would it really be necessary to set their filesystem to ro -
giving them a hard time, just because they like to use different kernels? I
think not.

There are many reasons to use different kernels: System-Rescue CD; kernel
building experiments etc.

So IMHO, a kernel that doesn't support a certain capability should  not do
*anything* with the bits used for that capability. It should make no
assumptions about them, and at best not even look at them. Just leave them as
they are.

At most, it might write a warning to /var/log/messages.

But it should not turn a working machine into a not working one for "reserved"
bits being in a "surprising" state. There are other kernels out there, they
might have some reason to set them as they are.

(Saying this, I assume *and hope!* that it is generally no problem to use an fs
that has these flags set with a kernel not supporting them - apart from the
missing extra functionality.)

This is just my naive opinion; I'm writing it however as someone who sees more
and more complexity and unforeseen dependencies with bad side effects added to
all areas of computing - often by people that were just a little bit too
caring, or made too narrow assumptions on other peoples' usage scenarios.

Thank you very much again, and kind regards, Joerg

-- 
You are receiving this mail because:
You are watching the assignee of the bug.