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: <200910272142.n9RLgB7f026211@demeter.kernel.org>
Date:	Tue, 27 Oct 2009 21:42:11 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 #135 from Eric Sandeen <sandeen@...hat.com>  2009-10-27 21:42:09 ---
(In reply to comment #134)

> Example issues that are exclusive to the root filesystem and would never 
> be an issue on any other filesystem (exactly due to the "mount ro first, 
> fsck later" behavior of root):
> 
>  - flaky in-kernel recovery code might trash more than it fixes, and would 
>    never trigger for the "fsck first" case because fsck would already have 
>    done it.

Yep, but I didn't have auto-fsck in my non-root testing, and I did "mount -o
ro" followed by "e2fsck -a" on it to try to "be like /", and didn't see it. 
Though I'll re-check just to be sure.

>  - flaky user-mode fsck doesn't understand that the kernel already did 
>    recovery, and re-does it.

It should print out a message if it's recovering again, we should see it in the
logs... and I don't think I have.

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

Could probably test this theory by forcing an immediate reboot if e2fsck does
recovery on a readonly mounted fs.

>  - even if every filesystem cache is physically indexed (ie using the 
>    buffer cache rather page cache), there may be various cached values 
>    that the kernel keeps around in separate caches, like the superblock 
>    compatibility bits, free block counts, etc. fsck might change them, but 
>    does 'remount,rw' always re-read them?

same test above would help determine this, I think.

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