The loop in clear_user_pages() iterates over all pages and calls
clear_user_page() for each of them. During the loop "vaddr" is modified.
However on sparc clear_user() is a macro which does not use "vaddr".
The compiler sees a variable which is modified but never used and emits
a warning for that:

	include/linux/highmem.h: In function 'clear_user_pages':
	include/linux/highmem.h:234:63: warning: parameter 'vaddr' set but not used [-Wunused-but-set-parameter=]
		static inline void clear_user_pages(void *addr, unsigned long vaddr,

Other architectures use an inline function for clear_user_page() which
avoids the warning. This is not possible on sparc, as
sparc_flush_page_to_ram() is not yet declared where clear_user_page() is
defined. Including cacheflush_32.h will trigger recursive and lots of
other issues.

So hide the warning with a cast to (void) instead.

While we are here, do the same for copy_user_page().

Fixes: 62a9f5a85b98 ("mm: introduce clear_pages() and clear_user_pages()")
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
Changes in v2:
- Put parens around vaddr.
- Link to v1: https://patch.msgid.link/20260524-sparc-clear_user_page-v1-1-baa5b90e5d0d@weissschuh.net
---
 arch/sparc/include/asm/page_32.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/sparc/include/asm/page_32.h b/arch/sparc/include/asm/page_32.h
index c1bccbedf567..9f0b54f70908 100644
--- a/arch/sparc/include/asm/page_32.h
+++ b/arch/sparc/include/asm/page_32.h
@@ -20,10 +20,12 @@
 #define clear_user_page(addr, vaddr, page)	\
 	do { 	clear_page(addr);		\
 		sparc_flush_page_to_ram(page);	\
+		(void)(vaddr);			\
 	} while (0)
 #define copy_user_page(to, from, vaddr, page)	\
 	do {	copy_page(to, from);		\
 		sparc_flush_page_to_ram(page);	\
+		(void)(vaddr);			\
 	} while (0)
 
 /* The following structure is used to hold the physical

---
base-commit: d87895ce6e45997825cfe1b3565a1843e8ac8011
change-id: 20260523-sparc-clear_user_page-7448669a2476

Best regards,
--  
Thomas Weißschuh <linux@weissschuh.net>

On Mon, 25 May 2026 10:36:21 +0200 Thomas Weißschuh <linux@weissschuh.net> wrote:

> The loop in clear_user_pages() iterates over all pages and calls
> clear_user_page() for each of them. During the loop "vaddr" is modified.
> However on sparc clear_user() is a macro which does not use "vaddr".
> The compiler sees a variable which is modified but never used and emits
> a warning for that:
> 
> 	include/linux/highmem.h: In function 'clear_user_pages':
> 	include/linux/highmem.h:234:63: warning: parameter 'vaddr' set but not used [-Wunused-but-set-parameter=]
> 		static inline void clear_user_pages(void *addr, unsigned long vaddr,
> 
> Other architectures use an inline function for clear_user_page() which
> avoids the warning. This is not possible on sparc, as
> sparc_flush_page_to_ram() is not yet declared where clear_user_page() is
> defined. Including cacheflush_32.h will trigger recursive and lots of
> other issues.
> 
> So hide the warning with a cast to (void) instead.
> 
> While we are here, do the same for copy_user_page().

A pleasing solution to these sorts of problems is often "don't use
macros".  Other architectures use inlined C for these functions - will
that work for sparc?

On 2026-05-25 10:44:39-0700, Andrew Morton wrote:
> On Mon, 25 May 2026 10:36:21 +0200 Thomas Weißschuh <linux@weissschuh.net> wrote:
> 
> > The loop in clear_user_pages() iterates over all pages and calls
> > clear_user_page() for each of them. During the loop "vaddr" is modified.
> > However on sparc clear_user() is a macro which does not use "vaddr".
> > The compiler sees a variable which is modified but never used and emits
> > a warning for that:
> > 
> > 	include/linux/highmem.h: In function 'clear_user_pages':
> > 	include/linux/highmem.h:234:63: warning: parameter 'vaddr' set but not used [-Wunused-but-set-parameter=]
> > 		static inline void clear_user_pages(void *addr, unsigned long vaddr,
> > 
> > Other architectures use an inline function for clear_user_page() which
> > avoids the warning. This is not possible on sparc, as
> > sparc_flush_page_to_ram() is not yet declared where clear_user_page() is
> > defined. Including cacheflush_32.h will trigger recursive and lots of
> > other issues.
> > 
> > So hide the warning with a cast to (void) instead.
> > 
> > While we are here, do the same for copy_user_page().
> 
> A pleasing solution to these sorts of problems is often "don't use
> macros".  Other architectures use inlined C for these functions - will
> that work for sparc?

Probably yes. But it would require a major reshuffling of the header
files to get the dependencies right. So I went with the easy solution to
avoid a lot of churn. As I tried to explain this in the patch message.


Thomas

On Mon, 25 May 2026 21:48:14 +0200 Thomas Weißschuh <linux@weissschuh.net> wrote:

> On 2026-05-25 10:44:39-0700, Andrew Morton wrote:
> > On Mon, 25 May 2026 10:36:21 +0200 Thomas Weißschuh <linux@weissschuh.net> wrote:
> > 
> > > The loop in clear_user_pages() iterates over all pages and calls
> > > clear_user_page() for each of them. During the loop "vaddr" is modified.
> > > However on sparc clear_user() is a macro which does not use "vaddr".
> > > The compiler sees a variable which is modified but never used and emits
> > > a warning for that:
> > > 
> > > 	include/linux/highmem.h: In function 'clear_user_pages':
> > > 	include/linux/highmem.h:234:63: warning: parameter 'vaddr' set but not used [-Wunused-but-set-parameter=]
> > > 		static inline void clear_user_pages(void *addr, unsigned long vaddr,
> > > 
> > > Other architectures use an inline function for clear_user_page() which
> > > avoids the warning. This is not possible on sparc, as
> > > sparc_flush_page_to_ram() is not yet declared where clear_user_page() is
> > > defined. Including cacheflush_32.h will trigger recursive and lots of
> > > other issues.
> > > 
> > > So hide the warning with a cast to (void) instead.
> > > 
> > > While we are here, do the same for copy_user_page().
> > 
> > A pleasing solution to these sorts of problems is often "don't use
> > macros".  Other architectures use inlined C for these functions - will
> > that work for sparc?
> 
> Probably yes. But it would require a major reshuffling of the header
> files to get the dependencies right. So I went with the easy solution to
> avoid a lot of churn. As I tried to explain this in the patch message.

Oh, OK, thanks, reading skills, sorry for noise.