linux-ext4 - Re: [PATCH]:resize2fs:adjust the inode before inode

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:	Sat, 18 Apr 2009 23:21:27 -0400
From:	Theodore Tso <tytso@....edu>
To:	Gui Xiaohua <guixh@...fujitsu.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH]:resize2fs:adjust the inode before inode_tables were
	covered

On Thu, Mar 12, 2009 at 04:14:46PM +0800, Gui Xiaohua wrote:
> Hi Ted
> There is a problem in your patch for resize2fs -M.
> You unmark the inode_table block in new fs,the blocks 
> which needed to be moved will cover the the inode_table
> blocks with its content.In inode_scan_and_fix func, we will
> scan the inode which in the old fs, but the inode table block
> had been coverd,then error occurs.
> I had fixed the problem through adjust the inode before blocks
> be moved.

Hi Gui,

Thanks for pointing out this problem.  It turns out there is an easier
solution, which involves reserving the blocks in the reserved_blocks
bitmap.  This prevents them from being reused, thus avoiding the
problem of old inode table getting overwritten before the inodes have
a chance to be moved.

Your solution has the advantage of not needing to reserve as much
"slop space", but the down side is that if the resize2fs is
interrupted after the inode table is overwritten but before the
directory blocks are updated to point at the new locations of the
inodes on disk, it would be much harder to recover the filesystem
after being interupted at such a bad point.

This problem could be solved by relocating the inodes first, then
updating the directory references, and then doing the block
relocations afterwards, but that would be a much larger change to
resize2fs.  The changes I elected to make, which I have just posted to
linux-ext4, and which you can see here:

    http://article.gmane.org/gmane.comp.file-systems.ext4/12762

... solve the problem in a much smaller set of changes.

    	      	      	   		    - 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