linux-ext4 - Re: New ext4 patchset 2.6.26-rc8-ext4-1

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: <20080705175047.GA11243@infradead.org>
Date:	Sat, 5 Jul 2008 13:50:47 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Theodore Ts'o <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: New ext4 patchset 2.6.26-rc8-ext4-1

On Sat, Jul 05, 2008 at 01:19:04PM -0400, Theodore Ts'o wrote:
> Alex Tomas (2):
>     * vfs: add basic delayed allocation support
>     * ext4: Add basic delayed allocation support

Strong NACK.  For one thing the code added to mpage.c doesn't belong
there.  It's far inferior to the existing delalloc code we already have
and that could be made generic easily, or the next generation code
developed by Chris mason.  It's an ext4-specific hack and doesn't belong
into common code.  I'm pretty sure we agreed on not having it in
common code long ago.

Also the code still deals with the !buffer_mapped and no buffers on page
cases all over which isn't needed anymore with ->page_mkwrite implemented.
Similarly the !get_block case in mpage_da_writepages doesn't make any
sense - it's never used and if people would want to use
generic_writepages they could trivially just call it directly.

And please fix up the indentation of the new buffer_delay checks in
fs/buffer.c, the && belongs on the end of the previous line, and the
second line of the conditional should not be indented the same amount
as the code inside the conditional block.
--
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