linux-ext4 - Re: [PATCH 17/24] e2fsck: reserve blocks for root/lost+found directory repair

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] [day] [month] [year] [list]

Date:	Fri, 25 Jul 2014 13:19:11 -0700
From:	"Darrick J. Wong" <darrick.wong@...cle.com>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 17/24] e2fsck: reserve blocks for root/lost+found
 directory repair

On Fri, Jul 25, 2014 at 08:12:53AM -0400, Theodore Ts'o wrote:
> On Fri, Jul 18, 2014 at 03:54:22PM -0700, Darrick J. Wong wrote:
> > If we think we're going to need to repair either the root directory or
> > the lost+found directory, reserve a block at the end of pass 1 to
> > reduce the likelihood of an e2fsck abort while reconstructing
> > root/lost+found during pass 3.
> 
> Can you say more about when this situation arises?  The only thing I
> can think of is if there are a large number of blocks that need to be
> cloned during passes 1b/c/d?

Yep, that's one of the scenarios that this patch fixes -- if / is corrupt and
duplicate processing allocates all the free blocks in the FS, we end up with an
unfixable FS -- there's a big file somewhere, but no directory structure; the
only way to repair would be to run debugfs -w to find and delete files, and
re-run e2fsck.  Granted, in this situation, you'd end up in a nasty loop of
running fsck, mounting the FS long enough to delete a big file or two,
unmounting, and rerunning fsck, but that's less troublesome than mucking with
debugfs.

This wasn't actually how I found the bug.  What really happened was that I
corrupted an extent in a directory such that the lblk was a really huge number.
The directory processing code would then try to "fill in" the "hole" by
allocating tons of blocks, typically until there weren't any free blocks left.
Then, any attempt to repair / or /lost+found would abort because there weren't
any free blocks.  Of course, this behavior is fixed by patch #18, so it's no
longer a good reproducer.

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