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  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
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

--- Comment #5 from Joerg M. Sigle ( ---
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.

Powered by blists - more mailing lists