linux-ext4 - Re: [RFC PATCH] ext4: Fix the locking with respect to ext3 to ext4 migrate.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 11 Mar 2008 16:25:37 +0100
From:	Jan Kara <jack@...e.cz>
To:	Andreas Dilger <adilger@....com>
Cc:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	Mingming Cao <cmm@...ibm.com>, tytso@....edu,
	sandeen@...hat.com, linux-ext4@...r.kernel.org
Subject: Re: [RFC PATCH] ext4: Fix the locking with respect to ext3 to ext4 migrate.

> On Mar 07, 2008  17:01 +0530, Aneesh Kumar K.V wrote:
> > On Fri, Mar 07, 2008 at 03:17:33AM -0800, Mingming Cao wrote:
> > > How about we start a journal with estimated worse case transaction
> > > credits  and then take the i_data_sem down? So that we could ensure that
> > > whenever the i_data_sem is hold, the i_data is protected. That is what
> > > currently DIO does, I think. It would be nice to avoid introducing
> > > another semaphore to protect i_data for migration if we could.
> > 
> > Estimating transaction for a single page directIO write may be easy. But
> > in case of migrate it involves new blocks allocated to carry the extents
> > and also we free the indirect blocks of ext3 and that would involve
> > update of bitmap from different groups. I am not sure we will be able to
> > come up with a value. But if yes and if we can get that many credits
> > from journal i agree that would be better than introducing a new
> > semaphore.
> 
> Agreed - and if we have a generic routine to calculate the journal
> credits needed for a full-file (or better a range) indirect block
> operation (including bitmaps, group descriptors, and [dt]indirect
> blocks).
> 
> I don't think there would be a serious failure case if it wasn't possible
> to convert a block-mapped file to extent-mapped while it was mmapped.
> At worst the administrator would need to do that some time later, or
> after a system reboot, so long as the conversion actually failed if the
> file had any mmaps.  If this same requirement is introduced when we
> get defrag for ext4 (because the block mapping is changing on the file)
> then we may have to reconsider the benefits of the more complex code.
  I agree here. IMHO the better option would be to just build the
extent-tree for converted inode on best-effort basis. If we find in
the end that someone has allocated new block to the file (via mmap
filling a hole) while we are converting, we can just cancel the
conversion. Because I think the cost of extra rwsem (both in terms of
additional memory needed for each inode structure and in time needed for
rwsem acquisitions) is more than I as a user would like to bear given
how rare the conversion is.

> Note we can also use the "journal credits needed" for fixing truncate in
> a similar manner to do it all in a single transaction to avoid zeroing
> all of the indirect blocks.  All that would be needed for trunate is to
> call the above function, update the on-disk i_size, possibly zero out the
> partially-truncated block, and update the group descriptors and bitmaps.
> That would also allow "undelete" to work on ext3 again because the
> inode i_blocks and indirect blocks wouldn't be zeroed out anymore,
> like it was in ext2.

								Honza
-- 
Jan Kara <jack@...e.cz>
SuSE CR Labs
--
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