linux-ext4 - Re: Uninitialized extent races

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: <20121221031151.GA5014@thunk.org>
Date:	Thu, 20 Dec 2012 22:11:51 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Jan Kara <jack@...e.cz>
Cc:	Dmitry Monakhov <dmonakhov@...nvz.org>, linux-ext4@...r.kernel.org
Subject: Re: Uninitialized extent races

On Fri, Dec 21, 2012 at 02:25:26AM +0100, Jan Kara wrote:
> Am I missing something Dmitry? Also I was wondering about one thing: Does
> anybody see a problem with disabling merging of uninitialized extents
> completely? It would simplify the code (end_io conversion doesn't need to
> potentially split extents) and the case when we really want to merge
> extents - i.e., when someone calls fallocate() on small chunks - doesn't
> seem like the case we need to optimize for? 

Which case specifically are you talking about here?

Are you talking about the merging of _formerly_ uninitialized extents?
i.e., what keeps the extent tree from exploding if you fallocate one
megabyte region, and then write to all 256 blocks of that one megabyte
region, except in a random order?

Or something else?

> Also it would bound the amount of transaction credits we need for
> conversion to 1 block which would make it easier for me to change
> ext4 to clear PageWriteback only after extent conversion is done
> (again code simplification, more uniform handling of page
> writeback).

So I'm confused.  If it's the case that we're thinking about, we only
need a single transaction credit, because we're not currently merging
across adjacent interior extent tree blocks.

Can you be a bit more explicit about which case you're thinking about?
I do agree that the extent tree code is too complicated, but we also
have the problem that we probably been more merging, not less, since
we can already end up with a case where you start with a single extent
tree block after fallocating a gigabyte or two.  Then after writing
randomly into that gigabyte file using AIO, we can end up with a very
deep, spindly extent tree containing multiple interior extent tree
blocks, because we're not doing sufficient merging --- and in
particular, we currently have no way at all of decreasing the depth of
the extent tree.

						- 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