linux-ext4 - Re: Help on Implementation of EXT3 type Ordered Mode in EXT4

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, 12 Feb 2010 15:07:26 -0500
From:	tytso@....edu
To:	Kailas Joshi <kailas.joshi@...il.com>
Cc:	linux-ext4@...r.kernel.org, Jan Kara <jack@...e.cz>,
	Jiaying Zhang <jiayingz@...gle.com>
Subject: Re: Help on Implementation of EXT3 type Ordered Mode in EXT4

On Fri, Feb 12, 2010 at 08:52:15AM +0530, Kailas Joshi wrote:
> Won't this get fixed by performing early reservations as mentioned in
> my scheme? We are reserving required credits in the path of write
> system call and these will be kept reserved until transaction commit.
> So, the journal space for allocation at commit will be guaranteed.

Yes, if you account for these separately.  One challenge is
over-estimating the needed credits will be tricky.  If we go down this
path, be sure that the bonnie style write(fd, &ch, 1) in a tight loop
doesn't end up reserving a separate set of credits for each write
system call to the same block.  (It can be done; if the DA block is
already instantiated, you can assume that credits have already been
reserved.)

> Sorry, I didn't understand why processes need to be suspended.
> In my scheme, I am issuing magic handle only after locking the current
> transaction.  AFAIK after the transaction is locked, it can receive the
> block journaling requests for already created handles(in our case, for
> already reserved journal space), and the new concurrent requests for
> journal_start() will go to the new current transaction. Since, the
> credits for locked transaction are fixed (by means of early
> reservations) we can know whether journal has enough space for the new
> journal_start(). So, as long as journal has enough space available,
> new processes need now be stalled.

But while you are modifying blocks that need to go into the journal
via the locked (old) transaction, it's not safe to start a new
transaction and start issuing handles against the new transaction.

Just to give one example, suppose we need to update the extent
allocation tree for an inode in the locked/committing transaction as
the delayed allocation blocks are being resolved --- and in another
process, that inode is getting truncated or unlinked, which also needs
to modify the extent allocation tree?  Hilarty ensues, unless you use
a block all attempts to create a new handle (practically speaking, by
blocking all attempts to start a new transaction), until this new
delayed allocation resolution phase which you have proposed is
complete.

							- 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