On 4/10/07, Anton Altaparmakov <aia21@xxxxxxxxx> wrote:
On 10 Apr 2007, at 07:10, Andrew Morton wrote:
> On Mon, 09 Apr 2007 21:31:37 -0700 Nate Diller
> <nate.diller@xxxxxxxxx> 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@xxxxxxxxx>
>>
>> ---
>>
>> 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.
Nate, I think you either do not understand what the KM_* constants
passed to kmap_atomic() mean or you were overeager in your code
replacement... You really, really cannot replace KM_BIO_SRC_IRQ with
KM_USER0 in the NTFS i/o completion handler without trashing people's
data left right an centre!
good catch, I was indeed careless on that one. I just double checked
all the other changes and that was the only non-KM_USER0 that slipped
through. Thanks!
I will submit a new patch later today that fixes this problem and the
issues AKPM raised.
NATE
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
