public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Nate Diller <nate.diller@gmail.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 1/2] fs: use memclear_highpage_flush to zero page data
Date: Mon, 9 Apr 2007 23:10:06 -0700	[thread overview]
Message-ID: <20070409231006.242a8304.akpm@linux-foundation.org> (raw)
In-Reply-To: <20070410043137.19370.2295.patchbomb.py@localhost>

On Mon, 09 Apr 2007 21:31:37 -0700 Nate Diller <nate.diller@gmail.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@gmail.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.


  parent reply	other threads:[~2007-04-10  6:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-10  4:31 [PATCH 1/2] fs: use memclear_highpage_flush to zero page data Nate Diller
2007-04-10  4:31 ` [PATCH 2/2] fs: use simple_prepare_write " Nate Diller
2007-04-10  6:10 ` Andrew Morton [this message]
2007-04-10  9:37   ` [PATCH 1/2] fs: use memclear_highpage_flush " Anton Altaparmakov
2007-04-10 21:22     ` Nate Diller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070409231006.242a8304.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nate.diller@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox