linux-ext4 - [Bug 14354] Bad corruption with 2.6.32-rc1 and upwards

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: <200910292155.n9TLtcIp012856@demeter.kernel.org>
Date:	Thu, 29 Oct 2009 21:55:38 GMT
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 14354] Bad corruption with 2.6.32-rc1 and upwards

http://bugzilla.kernel.org/show_bug.cgi?id=14354

--- Comment #148 from Theodore Tso <tytso@....edu>  2009-10-29 21:55:36 ---
>>  - virtually indexed caches might be loaded by the mount, and when you do 
>>    fsck later, the fsck writes back through the physically indexed direct 
>>    device. So the mounted root filesystem may never see those changes, 
>>    even after you re-mount it 'rw'.
>
>Yes, I've been worried about this... but would this be new?

Eric, Linus,

If fsck ever modifies the filesystem, it sets bit 0 in the exit status code.  
For the root file system, bit 1 is set as well.  To quote the fsck man page:

       The exit code returned by fsck is the sum of the following conditions:
            0    - No errors
            1    - File system errors corrected
            2    - System should be rebooted
            4    - File system errors left uncorrected
            8    - Operational error
            16   - Usage or syntax error
            32   - Fsck canceled by user request
            128  - Shared library error
       The exit code returned when multiple file systems are  checked  is  the
       bit-wise OR of the exit codes for each file system that is checked.

Distribution init scripts are supposed to force a reboot when the root file
system is checked, and fsck returns a non-zero exit code.   This should avoid
the problem that Linus is afraid of.   Of course, Ubuntu Karmic *does* have a
new set of fancy-shamncy init scripts that is supposed to run (some) fsck's in
parallel with the rest of the boot process.  Presumably this doesn't include
critical file systems such as the root and whatever filesystems might be
supplying /var or /usr.  But maybe Karmic introduced a bug and the init scripts
aren't forcing a reboot after fsck prints "*** REBOOT LINUX ***" and returns
with an exit status code of 3 (file system errors correct, system should be
rebooted).

Note though that this shouldn't happen on a simple unclean shutdown, since the
journal replay takes place before the root file system is initially mounted
(even read-only).   [n.b. The fact that Avery was using -o noload, is not
normal, and I'm not sure what he was trying to test.]

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html