linux-ext4 - Re: [PATCH 0/3] ext4: don't use quota reservation for speculative metadata blocks

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: <20100412134228.GL1849@thunk.org>
Date:	Mon, 12 Apr 2010 09:42:28 -0400
From:	tytso@....edu
To:	Dmitry Monakhov <dmonakhov@...nvz.org>
Cc:	Jan Kara <jack@...e.cz>, Eric Sandeen <sandeen@...hat.com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 0/3] ext4: don't use quota reservation for speculative
 metadata blocks

On Mon, Apr 12, 2010 at 05:33:14PM +0400, Dmitry Monakhov wrote:
> BTW I'm too familiar with cross-devel-tree process
> If tytso@ will get the patchset will you get an quota-related patches
> to linux-fs tree too? Otherwise everybody have to wait for ext4-tree
> push to linus's tree and when to linux-fs.

I've already asked Jan if he would mind my carrying the quota patches
in the ext4 tree, since I believe there's less chance of patch
collisions with upcoming changes in the quota tree than if they were
carried in the quota tree and we had to worry about changes to the
ext4 tree.

These patches are also low-risk enough (they'll either work or they
won't, and it's not hard to desk-check them for correctness) that we
could push them to Linus now before the merge window, and see if he's
willing to take them.  I have some data corruption bugfixes I need to
push to Linus anyway....  I dunno if Linus will be willing to take
them, but that's the other approach.

					- 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