linux-ext4 - Re: [RFC PATCH] ext2: Retry block allocation if new blocks are allocated from system zone.

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]

Message-ID: <20080326073800.GA7325@skywalker>
Date:	Wed, 26 Mar 2008 13:08:00 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Andreas Dilger <adilger@....com>
Cc:	cmm@...ibm.com, linux-ext4@...r.kernel.org
Subject: Re: [RFC PATCH] ext2: Retry block allocation if new blocks are
	allocated from system zone.

On Tue, Mar 25, 2008 at 05:56:49PM -0600, Andreas Dilger wrote:
> On Mar 26, 2008  00:26 +0530, Aneesh Kumar K.V wrote:
> > If the block allocator gets blocks out of system zone ext2 calls
> > ext2_error. But if the file system is mounted with errors=continue
> > retry block allocation. We need to mark the system zone
> > blocks as in use to make sure retry don't pick them again
> > 
> > System zone is the block range mapping block bitmap, inode bitmap
> > and inode table.
> 
> Nack * 3.  It appears that this will spin in a loop, because retry_alloc:
> will not change the group that is being used, and extN_valid_block_bitmap()
> does nothing to fix up the bitmap to avoid re-allocating the same blocks.


As also discussed on irc, ext2_try_to_allocate(fs/ext2/balloc.c:738)
marks the blocks allocated as in use. So we will not really spin in
loop here. Same is true for ext3 and ext4. (fs/ext4/balloc.c:1066) for
mballoc it is done as a part of patch.

> 
> Instead, it seems safest that extN_new_blocks() should skip the group
> entirely after marking the group as having no free blocks, so the allocator
> will no longer choose it.  This also means that when freeing blocks it
> needs to watch out for underflow of the ->bg_free_blocks_count value,
> which is itself a good safety measure.

Agreed. As you suggested on irc, i will try to introduce EXT4_BG_CORRUPT
and ignore the group which has EXT4_BG_CORRUPT set in block allocation.
I would also try to do e2fsck changes that will clear this flag after
fixing the bitmap corruption.

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