linux-ext4 - Re: [PATCH] ext4: clarify ext4_error message in ext4_mb_generate_buddy

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:	Tue, 8 Jul 2014 15:16:40 +0200 (CEST)
From:	Lukáš Czerner <lczerner@...hat.com>
To:	"Theodore Ts'o" <tytso@....edu>
cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	stable@...r.kernel.org
Subject: Re: [PATCH] ext4: clarify ext4_error message in
 ext4_mb_generate_buddy_error()

On Tue, 8 Jul 2014, Theodore Ts'o wrote:

> Date: Tue, 8 Jul 2014 08:54:54 -0400
> From: Theodore Ts'o <tytso@....edu>
> To: Lukáš Czerner <lczerner@...hat.com>
> Cc: Ext4 Developers List <linux-ext4@...r.kernel.org>, stable@...r.kernel.org
> Subject: Re: [PATCH] ext4: clarify ext4_error message in
>     ext4_mb_generate_buddy_error()
> 
> On Tue, Jul 08, 2014 at 09:03:48AM +0200, Lukáš Czerner wrote:
> > 
> > It is a bit better, even though strictly speaking it's not
> > right, because it is not block bitmap alone, but rather aggregation
> > of block bitmap and preallocations. But for the user this is really
> > an implementation detail they do not need to worry about I guess.
> 
> Actually, no, because the preallocations aren't reflected in the
> in-block bitmap.

But the "bitmap" argument we're getting in ext4_mb_generate_buddy() is
not just the original on disk bitmap, is it ? It's aggregation of the on
on disk block bitmap and preallocation (this is done in
ext4_mb_init_cache()). Or am I missing something ?

> 
> And, oh sh*t, I wonder if that's the cause of the
> ext4_mb_generate_buddy().  We don't need the buddy bitmaps to allocate
> out of the preallocations, and it's not needed by
> ext4_mb_mark_diskspace_used().  If the buddy bitmaps have been pushed
> out of the page cache between when the blocks were originally
> preallocated and when we try to use some preallocated blocks, and then
> we have a race between ext4_mb_mark_diskspace_used() and
> ext4_mb_buddy_generate(), that could explain the discrepancy between
> the block group descriptors and the loaded buddy bitmap.

ext4_mb_generate_buddy() is run under the group lock and the actual
ext4_set_bits() in ext4_mb_mark_diskspace_used as well. And again in
ext4_mb_generate_buddy() we do take into account preallocations
which will be marked as used in the buddy bitmap.

> 
> If this is what's going on, it doesn't explain why we hacen't been
> seeing this until post 3.15, though....
> 
> 				- 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
>