From nobody Mon Jun 8 23:59:14 2026 Received: from todd.t-8ch.de (todd.t-8ch.de [159.69.126.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 775963E1729 for ; Mon, 25 May 2026 08:33:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=159.69.126.157 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779698036; cv=none; b=LV/+U5bzdoT9hFi1nkO9XKy25lNvnPPnus7BxJH5o9UhVQMgEJsKZTVGP/VRS+QYhhi6UmJnjV18GtiwdpJ6folVz6odXVr6PGOKmR2JwenAyZszMrYvFoELAv1T3AK64YF8IWdsDJU2JerPW6HeXfN58dtNbWKgAg2u3hq/IQo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779698036; c=relaxed/simple; bh=bzHbOMuipgyodW2udWwz1o3AzW1vdViW7ihguiilwA8=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=WvbS3Ak1EAZ010dba4YSDgFGnqLJKYYiBiTYTj9WrEbU1o1wKJnQ8XSplppVUWfoktiDmZNHkfbQOrXNQXw+/JDUS+s3gWwGho1U8mqZT9biE4qRd4MbjBnpYaIKn/9fKwVaBGAa84Qo7P/oUdBJWiurRm0mqiuIvVCGZ4Lv78I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=weissschuh.net; spf=pass smtp.mailfrom=weissschuh.net; dkim=pass (1024-bit key) header.d=weissschuh.net header.i=@weissschuh.net header.b=YllGPz+V; arc=none smtp.client-ip=159.69.126.157 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=weissschuh.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=weissschuh.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=weissschuh.net header.i=@weissschuh.net header.b="YllGPz+V" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=weissschuh.net; s=mail; t=1779698033; bh=bzHbOMuipgyodW2udWwz1o3AzW1vdViW7ihguiilwA8=; h=From:Date:Subject:To:Cc:From; b=YllGPz+VgUYVKnZZ9jhF1K1OmSPkJaSTBDJrVBU34LlP1qc/wwcEWTTSVON4tCeB0 5jcjiCcsWratPEsptjPD3PcSARqp690rZ3bzwmzD9ycbtZAbPlzBUAkRosGw56tnKx wCDokuNxFgtGFHpAHiXLaiJ2dd8jr5Y4mdpCIUPw= From: =?utf-8?q?Thomas_Wei=C3=9Fschuh?= Date: Mon, 25 May 2026 10:33:52 +0200 Subject: [PATCH v2] m68k: Avoid -Wunused-but-set-parameter in clear_user_page() Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260525-m68k-clear_user_page-v2-1-0c8981c6eca1@weissschuh.net> X-B4-Tracking: v=1; b=H4sIAAAAAAAC/22OSw6CMBCGr0K6tqYUaIor72EIgTrYqjzstKgh3 N2CGjcms/km/2siCNYAkl00EQujQdN3AfgmIkpX3QmoOQYmnHHBMp7QVsgLVVeobOmDtxyqoKk byUQSrskZCdbBQmMea+yheDP6+gzKLVkfhYWbD33uJ9MGXW+f65gxXr7f3vR/7xjTmKYqz5gQU qYc9ncwiKi019sOHCnmeX4B8SvRKuQAAAA= X-Change-ID: 20260523-m68k-clear_user_page-bf8063063f90 To: Geert Uytterhoeven , "David Hildenbrand (Red Hat)" , Andrew Morton , Ankur Arora Cc: linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org, Andreas Schwab , =?utf-8?q?Thomas_Wei=C3=9Fschuh?= X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1779698032; l=2109; i=linux@weissschuh.net; s=20221212; h=from:subject:message-id; bh=bzHbOMuipgyodW2udWwz1o3AzW1vdViW7ihguiilwA8=; b=m1oaqwHrlXLCfaytkgEp8ZvkM26fhfp1+wjB7gjBYlnJ/wE5g4m9epTCmD4/l9XCMOUnPXdOY K4zRgd/jG7/CGS9XKvpXrGBD2c/3JfA2EeeT+9sld/U5QzFFBAAYk1C X-Developer-Key: i=linux@weissschuh.net; a=ed25519; pk=KcycQgFPX2wGR5azS7RhpBqedglOZVgRPfdFSPB1LNw= 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 m68k 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=3D] 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 m68k, as dlush_dcache_page() is another macro which is not yet defined where clear_user_page() is defined. Including cacheflush_mm.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=C3=9Fschuh --- Changes in v2: - Put parens around vaddr. - Link to v1: https://patch.msgid.link/20260524-m68k-clear_user_page-v1-1-4= c950668842e@weissschuh.net --- arch/m68k/include/asm/page_mm.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/m68k/include/asm/page_mm.h b/arch/m68k/include/asm/page_m= m.h index ed782609ca41..0971a0651d49 100644 --- a/arch/m68k/include/asm/page_mm.h +++ b/arch/m68k/include/asm/page_mm.h @@ -55,10 +55,12 @@ static inline void clear_page(void *page) #define clear_user_page(addr, vaddr, page) \ do { clear_page(addr); \ flush_dcache_page(page); \ + (void)(vaddr); \ } while (0) #define copy_user_page(to, from, vaddr, page) \ do { copy_page(to, from); \ flush_dcache_page(page); \ + (void)(vaddr); \ } while (0) =20 extern unsigned long m68k_memoffset; --- base-commit: eed108edc1170404bbef9e7d0189d18a3cc354f5 change-id: 20260523-m68k-clear_user_page-bf8063063f90 Best regards, -- =20 Thomas Wei=C3=9Fschuh