[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070409231006.242a8304.akpm@linux-foundation.org>
Date: Mon, 9 Apr 2007 23:10:06 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Nate Diller <nate.diller@...il.com>
Cc: Alexander Viro <viro@...iv.linux.org.uk>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 1/2] fs: use memclear_highpage_flush to zero page data
On Mon, 09 Apr 2007 21:31:37 -0700 Nate Diller <nate.diller@...il.com> wrote:
> It's very common for file systems to need to zero part or all of a page, the
> simplist way is just to use kmap_atomic() and memset(). There's actually a
> library function in include/linux/highmem.h that does exactly that, but it's
> confusingly named memclear_highpage_flush(), which is descriptive of *how*
> it does the work rather than what the *purpose* is. So this patch renames
> the function to zero_page_data(), and calls it from the various places that
> currently open code it.
>
> Compile tested in x86_64.
>
> signed-off-by: Nate Diller <nate.diller@...il.com>
>
> ---
>
> drivers/block/loop.c | 6 ---
> fs/affs/file.c | 6 ---
> fs/buffer.c | 53 +++++--------------------------
> fs/direct-io.c | 8 +---
> fs/ecryptfs/mmap.c | 14 +-------
> fs/ext3/inode.c | 12 +------
> fs/ext4/inode.c | 12 +------
> fs/ext4/writeback.c | 12 +------
> fs/gfs2/bmap.c | 6 ---
> fs/mpage.c | 11 +-----
> fs/nfs/read.c | 10 ++---
> fs/nfs/write.c | 2 -
> fs/ntfs/aops.c | 32 +++---------------
> fs/ntfs/file.c | 47 +++++----------------------
> fs/ocfs2/aops.c | 5 --
> fs/reiser4/plugin/file/cryptcompress.c | 19 +----------
> fs/reiser4/plugin/file/file.c | 6 ---
> fs/reiser4/plugin/item/ctail.c | 6 ---
> fs/reiser4/plugin/item/extent_file_ops.c | 19 +++--------
> fs/reiser4/plugin/item/tail.c | 8 +---
> fs/reiserfs/file.c | 39 ++++++----------------
> fs/reiserfs/inode.c | 13 +------
> fs/xfs/linux-2.6/xfs_lrw.c | 2 -
> include/linux/highmem.h | 2 -
> mm/filemap_xip.c | 7 ----
> mm/truncate.c | 2 -
> 26 files changed, 78 insertions(+), 281 deletions(-)
>
Not sure that I agree with the name zero_page_data(). People might use it
to, err, zero a page's data. Whereas it is really only for use against
*user* pages. zero_user_page(), perhaps.
Plus..
This patch as presented causes me surprising amounts of trouble. I need to
split it up into
- core plus filesystems which don't have maintainers (for me to merge)
- filesystems which do have maintainers (one patch per), for
maintainers to merge.
- another patch for reiser4, to remain in -mm.
And this is actually not possible to do, because my merge and the subsystem
maintainers' merges will happen at different times. In the intervening
window, the kernel won't compile.
So instead I need to
- split off the reiser4 bit
- get acks from fs maintainers on the rest
- merge the whole thing in one hit (minus reiser4)
And I can do that, but it is the less preferable option.
The better way to do this merge is:
patch #1:
static inline void memclear_highpage_flush(...) __deprecated
{
zero_user_page(...);
}
patch #2..n: convert filesystems.
then, when all filesystems are converted, we're ready to remove
memclear_highpage_flush(). But we do that six months later - let's not
screw out-of-tree fs maintainers (and their users) unnecessarily.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists