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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 07 Mar 2008 16:47:51 -0700
From:	Andreas Dilger <adilger@....com>
To:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc:	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.

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.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

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