linux-ext4 - Re: new block group bitmaps not being initialized after resize!?

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: <20130113043615.GE19503@thunk.org>
Date:	Sat, 12 Jan 2013 23:36:15 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Andreas Dilger <adilger@...ger.ca>,
	Carlos Maiolino <cmaiolino@...hat.com>,
	linux-ext4@...r.kernel.org
Subject: Re: new block group bitmaps not being initialized after resize!?

On Fri, Jan 11, 2013 at 09:47:01AM -0600, Eric Sandeen wrote:
> > Zeroing the inode table but not setting the INODE_ZEROED flag
> > would not be harmful, but this seems to not be the case.
> 
> we appear to be not zeroing the table, and not setting INODE_ZEROED.
> But we should have set INODE_UNINIT, or zeroed it, right?

The flag names are confusing.  INODE_ZEROED means that the inode table
is not zero'ed.  This is correct.

INODE_UNINIT refers to the inode allocation bitmap not being
initialized, and what we are doing is correct as well.

What we should be doing is making sure that we kick off the lazyinit
thread.  So it's basically a missing call to
ext4_register_li_request(sb).

> Hum, but lazyinit will take some time to complete; in this case
> we resized, unmounted, ran fsck and everything was a mess.  Even if
> we'd started lazyinit I don't think that'ts enough, because we never
> flagged the group as uninit.

But as near as I can tell, at least with the latest upstream kernel,
the flags are being set correctly.  INODE_ZEROED is not being set, but
that's correct, because the inode table has not been zeroed.  

The real problem was the bug which was fixed by 93f905264; previous to
this commit, the unused inode count was incorrect.  My fault for not
understanding the consequences of this bug.  I was thinking in terms
of the e2fsck taking too long, but of course if there were previously
valid inodes in those blocks, e2fsck would in fact go crazy.  So that
commit really should have been marked cc: stable@...r.kernel.org.

Regards,

						- 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