deprecate memclear_highpage_flush deprecation warnings

PATCH In review Christoph Hellwig 2 participants 3 messages May 15, 2007

Subsystems (3)

NFS client MM core XFS filesystem

lore

Share & tools

lore

Christoph Hellwig

author

2007-05-15 12:25 UTC #0 lore raw

PATCH 1/1 deprecate memclear_highpage_flush deprecation warnings

Recent builds get tons of warnings about memclear_highpage_flush beeing deprecated. Turns out it's replaced by zero_user_page which takes an additional argument.

Now folks, deprecated is for actual functionality going away, there is no need to mark the old name deprecated for such a trivial paramter change and rename. This stuff should go to Linus in one patch that doesn't create utterly useless warnings and keeps around stale interfaces.

Here's a patch to kill memclear_highpage_flush and convert the reaming user to make the build a littler more silent, it's more than noisy enough due to all the useless addition of __deprecated or __must_check to widely used functionality and gcc stupid false positives.

Signed-off-by Christoph Hellwig <[email protected]>

fs/nfs/read.c +5 -5

Index: linux-2.6/fs/nfs/read.c
===================================================================
@@ -79,7 +79,7 @@ void nfs_readdata_release(void *data)
 static
 int nfs_return_empty_page(struct page *page)
 {
-	memclear_highpage_flush(page, 0, PAGE_CACHE_SIZE);
+	zero_user_page(page, 0, PAGE_CACHE_SIZE, KM_USER0);
 	SetPageUptodate(page);
 	unlock_page(page);
 	return 0;

@@ -103,10 +103,10 @@ static void nfs_readpage_truncate_uninit
 	pglen = PAGE_CACHE_SIZE - base;
 	for (;;) {
 		if (remainder <= pglen) {
-			memclear_highpage_flush(*pages, base, remainder);
+			zero_user_page(*pages, base, remainder, KM_USER0);
 			break;
 		}
-		memclear_highpage_flush(*pages, base, pglen);
+		zero_user_page(*pages, base, pglen, KM_USER0);
 		pages++;
 		remainder -= pglen;
 		pglen = PAGE_CACHE_SIZE;

@@ -130,7 +130,7 @@ static int nfs_readpage_async(struct nfs
 		return PTR_ERR(new);
 	}
 	if (len < PAGE_CACHE_SIZE)
-		memclear_highpage_flush(page, len, PAGE_CACHE_SIZE - len);
+		zero_user_page(page, len, PAGE_CACHE_SIZE - len, KM_USER0);
 
 	nfs_list_add_request(new, &one_request);
 	if (NFS_SERVER(inode)->rsize < PAGE_CACHE_SIZE)

@@ -532,7 +532,7 @@ readpage_async_filler(void *data, struct
 			return PTR_ERR(new);
 	}
 	if (len < PAGE_CACHE_SIZE)
-		memclear_highpage_flush(page, len, PAGE_CACHE_SIZE - len);
+		zero_user_page(page, len, PAGE_CACHE_SIZE - len, KM_USER0);
 	nfs_pageio_add_request(desc->pgio, new);
 	return 0;
 }

fs/nfs/write.c +1 -1

Index: linux-2.6/fs/nfs/write.c
===================================================================
@@ -168,7 +168,7 @@ static void nfs_mark_uptodate(struct pag
 	if (count != nfs_page_length(page))
 		return;
 	if (count != PAGE_CACHE_SIZE)
-		memclear_highpage_flush(page, count, PAGE_CACHE_SIZE - count);
+		zero_user_page(page, count, PAGE_CACHE_SIZE - count, KM_USER0);
 	SetPageUptodate(page);
 }

fs/xfs/linux-2.6/xfs_lrw.c +1 -1

Index: linux-2.6/fs/xfs/linux-2.6/xfs_lrw.c
===================================================================
@@ -159,7 +159,7 @@ xfs_iozero(
 		if (status)
 			goto unlock;
 
-		memclear_highpage_flush(page, offset, bytes);
+		zero_user_page(page, offset, bytes, KM_USER0);
 
 		status = mapping->a_ops->commit_write(NULL, page, offset,
 							offset + bytes);

include/linux/highmem.h +0 -6

Index: linux-2.6/include/linux/highmem.h
===================================================================
@@ -110,12 +110,6 @@ static inline void clear_highpage(struct
 		kunmap_atomic(kaddr, (km_type));		\
 	} while (0)
 
-static inline void __deprecated memclear_highpage_flush(struct page *page,
-			unsigned int offset, unsigned int size)
-{
-	zero_user_page(page, offset, size, KM_USER0);
-}
-
 #ifndef __HAVE_ARCH_COPY_USER_HIGHPAGE
 
 static inline void copy_user_highpage(struct page *to, struct page *from,

Andrew Morton

maintainer

2007-05-15 16:01 UTC #1 lore raw

Quoted 7 lines · On Tue, 15 May 2007 14:24:40 +0200 Christoph Hellwig <[email protected]> wrote:

Recent builds get tons of warnings about memclear_highpage_flush beeing deprecated. Turns out it's replaced by zero_user_page which takes an additional argument.
Now folks, deprecated is for actual functionality going away, there is no need to mark the old name deprecated for such a trivial paramter change and rename.

Yes, it's rather trivial, but memclear_highpage_flush() *is* going away.

Quoted 8 lines

This stuff should go to Linus in one
patch that doesn't create utterly useless warnings and keeps around stale interfaces.
Here's a patch to kill memclear_highpage_flush and convert the reaming user to make the build a littler more silent, it's more than noisy enough due to all the useless addition of __deprecated or __must_check to widely used functionality and gcc stupid false positives.

Patches have been prepared which convert all in-kernel users. I thought I'd dtrt and feed them through maintainers, but that takes time. The laggards are on cc ;)

Christoph Hellwig

author

2007-05-15 16:16 UTC #2 lore raw

Quoted 11 lines · Andrew Morton

Quoted 7 lines · On Tue, 15 May 2007 14:24:40 +0200 Christoph Hellwig <[email protected]> wrote:
Recent builds get tons of warnings about memclear_highpage_flush beeing deprecated. Turns out it's replaced by zero_user_page which takes an additional argument.
Now folks, deprecated is for actual functionality going away, there is no need to mark the old name deprecated for such a trivial paramter change and rename.
Yes, it's rather trivial, but memclear_highpage_flush() *is* going away.

Well, it's renamed to zero_user_page and gained an argument. We do changed like that all the time and don't put silly deprecation warnings in.

Quoted 8 lines

Quoted 4 lines
Here's a patch to kill memclear_highpage_flush and convert the reaming user to make the build a littler more silent, it's more than noisy enough due to all the useless addition of __deprecated or __must_check to widely used functionality and gcc stupid false positives.
Patches have been prepared which convert all in-kernel users. I thought I'd dtrt and feed them through maintainers, but that takes time. The laggards are on cc ;)

No, there is absolutely no point in feeding this through maintainers. For something as trivial as a rename and adding an argument doing one patch is enough and the right thing. We can't feed any trivial global search & replace through maintainer and generate warnings in the meantime.