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: <79B42851-940F-4A2A-A860-363867AF1C50@dilger.ca>
Date:	Mon, 14 Mar 2011 19:15:29 -0700
From:	Andreas Dilger <adilger@...ger.ca>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Why do we initialize block bitmaps in ext4_new_inode()

On 2011-03-14, at 10:44 AM, Theodore Ts'o wrote:
> Is there some subtle reason why ext4_new_inode() checked for
> uninitialized block bitmaps and initialized the block bitmaps in
> ext4_new_inode().  It's not immediately needed in that function, and I
> don't see any reason why initializing the inode table or inode
> allocation bitmap requires initializing the block bitmap.
> 
> Am I missing something?

The assumption when this was coded is that if the inode bitmap was in use, then the block bitmap must also be initialized in order to mark the inode bitmap block in use also.

If we think that the block allocator isn't in any danger of reallocating the inode bitmap block, or inode table blocks because the block bitmap is uninitialized, then it isn't strictly needed.  I think the added checks for blocks being allocated from system zones was added after the uninit_bg feature was written.

The correlation between block and inode bitmaps is also different due to flex_bg, which didn't exist when flex_bg was written.  If inodes are allocated from a group, it was formerly (w/o flex_bg) very likely that blocks will also be allocated from this group.  Any blocks that are allocated to inodes from that group will have that group as the goal block.  With flex_bg the correlation is less strong, but I'd be surprised if more inodes are allocated than blocks (i.e. initialized inode bitmap, but no need to initialize block bitmap), even in a flex_bg filesystem.

Cheers, Andreas





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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ