From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from flow-b8-smtp.messagingengine.com (flow-b8-smtp.messagingengine.com [202.12.124.143]) (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 8B79A3DB325; Tue, 14 Jul 2026 15:06:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.143 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784041609; cv=none; b=B7LuclGtoubL3LjtZR86ZEuoKpIU1ntgnkDD3n+qNVr34RY59XQEYRgheEGsnxciYgjU6lVOM2H4wcYZPJs52W+e/D1isnL7Xr5oaRp1G+EVCfHTJaKuS7YZ82vHyPObllS/kU1r8SmBTWaXaU275tEMsGJXQ9xZ1INLf7fe8TU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784041609; c=relaxed/simple; bh=mA4+7pYMGxjhhfpukSJW9caaxcbx3SxiZGdUMYmSxPQ=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=NKuAR70t57FIBibRF0Bossm6gm6BMjKW2t5aeMQ8ti3WlHeNJGRzfGGuEeM2Cob1Nqvpe7TmpdsBmkLePL6ndL7BdDA8zEvZPGJVZ+HJmKdbvwP5JVrSSB+E/HKyBqFSpAg4SpZLs9vju6aSXgArJrIR0Pg//t8IolYDm5cCVxY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de; spf=pass smtp.mailfrom=arndb.de; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b=lC/erCLu; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=P2Is4296; arc=none smtp.client-ip=202.12.124.143 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arndb.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b="lC/erCLu"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="P2Is4296" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailflow.stl.internal (Postfix) with ESMTP id BA8931300114; Tue, 14 Jul 2026 11:06:45 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-04.internal (MEProxy); Tue, 14 Jul 2026 11:06:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1784041605; x=1784048805; bh=ZP6AUuW+BQfE8xE/ZQO072//wuV0eV2xjCAbIlgM31o=; b= lC/erCLuPnd+85eOUScCipTGeubo7Y+8Nbyh1+57I+6xXdBoDdSehuLIxsmh2HLO Gfcr4H+yYUUF0gWhQcZ39olrjXYIB3EH4aVBfx4VLGDeFqPS72zMb3H9d90uNX8k zz8lXgdrCqdf/7AuatUtBNhm0NL79Q1d0iqxm33NkPMCzBYPirlWDhMeJRFXXN5v savQ552I+f/GXPtvOSZB+KVyiqYz332iX+8b0PkX4coG07s6fH9t6AWiZ70uapNZ E3x6bDNKSYPDwKx2XpxIJlbzgz9jNvejiFvyhC2KGvA+lXfnCC/cpKic+23jAvRQ d4KWFAzM0IHEpWv+Z06qxg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1784041605; x= 1784048805; bh=ZP6AUuW+BQfE8xE/ZQO072//wuV0eV2xjCAbIlgM31o=; b=P 2Is4296V2D7bPxP4OfD/5D7Kq9QzzJWaEr2ZS8h9n1FC5h3gc44hIRW168MQ1NKz cAX3gEU6FcRAtTLUc6oFd1xVk5w33G4tSYXpOUZaBMr+lY0bW+TJ7C1aN/CojXCl uLFpR/BAZQwAS/0a6/zl3MT/zyBZ9iI7TSJcDmJxKoRdFW1TzulzSOk/ll4APQKg 2/yVj7oKtP4EzYL5Un8JK+7aUS2b1iUDiRihfqd39uf1Dt5umjvjdzGgl5BlSKwt Y17YDnkqxpArMKtN5T4agfhMpGGh4/XPeBxsyf2+9SU3pPGAgVLD+9kdXmaWjyQI 7MegV7M/Xa/xRyYanIHKQ== X-ME-Sender: X-ME-Proxy-Cause: dmFkZTGcioZwMwHlgAe1l0bPf8gvE+LKXir3CyHGrFeNW0WDZMIbkar/MIvcDBI3bdb4tn TLcOIvj6s5d0LpuhCDRNM9/43oNLyRhEeFYvBVQIhT0xLYynAB1xtO2cewFtb0t6CtzMjX xv1R0eBlDof4dBuQ5arMoRTqIZurltnigWrb9ac9eD2HPc/CttnLB9ggEMsrZEqWcCtq83 6xwm7tIMawSMI0+OL6ui9SlZUBVzg8A1tzzj1Eqbu9g0mrqHl8ho3B9MTaQrnrFpmlPySP ctR1qy06L92hBLrpFsYUroefkz63x5l2nxv5qD0VrEvqmjLSOdjN4ImPYaXL/oGoYDNFBs 3UNDkt74/5VfVa1u/SRQoGn04/4YUxYH/2UmQve3eTutRLopyxE6b8vSHZpEdNYm7mnD7B QhnZdEbvTJwC09NdFzQNBKzSxXuA83892lZ7HcL5jlQbYL+PCaxgrFtpOX1Z45KxrBxdz7 NZiMxfOQQCOlRCa4qxgVD75cBKQI6J6n/qgr0757bn5MDLpvJWetIhWjcAuRHWI9FtpI0X 1if7Q0uLuUrlWj+WFZvcExqXcYRs1Kz740TGA0BdEZF7hqs1rjgdtu8xuvgNXvL+SwQPz5 OU+Kp9UGoHJCfh7v41OFx8T3SbkSgGNxkoPcfJimECrLvSmlSsaAWXUENfpA X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id A3DA81820082; Tue, 14 Jul 2026 11:06:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: ASU80-mPZ9gg Date: Tue, 14 Jul 2026 17:06:00 +0200 From: "Arnd Bergmann" To: "David Laight" Cc: "Pedro Falcato" , "Yeoreum Yun" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, Linux-Arch , kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, x86@kernel.org, linux-mm@kvack.org, kasan-dev@googlegroups.com, "linux-csky@vger.kernel.org" , linux-m68k@lists.linux-m68k.org, "linux-openrisc@vger.kernel.org" , "David Hildenbrand (Red Hat)" , "Russell King" , "Andrew Morton" , "Ankur Arora" , "Mike Rapoport" , "Magnus Lindholm" , "Christophe Leroy" , "Klara Modin" , "Huacai Chen" , "WANG Xuerui" , "Kirill A. Shutemov" , zhangtianyang@loongson.cn, wangyuli@aosc.io, "Thomas Bogendoerfer" , "Lorenzo Stoakes" , "Jason Gunthorpe" , "Catalin Marinas" , "Will Deacon" , "Ryan Roberts" , "Pasha Tatashin" , "Rohan McLure" , "Baolin Wang" , "Tejun Heo" , "Kevin Brodsky" , "Anup Patel" , atish.patra@linux.dev, "Paul Walmsley" , "Palmer Dabbelt" , "Albert Ou" , "Alexandre Ghiti" , "Dave Hansen" , "Andy Lutomirski" , "Peter Zijlstra" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "H. Peter Anvin" , "Johannes Weiner" , "Michal Hocko" , qi.zheng@linux.dev, "Shakeel Butt" , "Kairui Song" , "Barry Song" , "Axel Rasmussen" , "Yuanchu Xie" , "Wei Xu" , "Andrey Ryabinin" , "Alexander Potapenko" , "Andrey Konovalov" , "Dmitry Vyukov" , "Vincenzo Frascino" , "Anshuman Khandual" , "Yang Shi" , chaitanyas.prakash@arm.com, "Ard Biesheuvel" , guoren , yang.li85200@gmail.com, "Alexander Viro" , "Dinh Nguyen" , "schuster.simon@siemens-energy.com" , "Vivian Wang" , junhui.liu@pigmoral.tech, "Muchun Song" , "Vishal Moola (Oracle)" , "Nam Cao" , "Pavel Machek" , djbw@kernel.org, yu-cheng.yu@intel.com, "Baolu Lu" , "Jonathan Cameron" , "Coiby Xu" , "Andreas Larsson" , "Liam R. Howlett" , "Vlastimil Babka (SUSE)" , "Suren Baghdasaryan" , "Michal Hocko" , "Geert Uytterhoeven" , "Stafford Horne" , "Jonas Bonn" , "Stefan Kristiansson" Message-Id: In-Reply-To: <20260714143450.61a94085@pumpkin> References: <20260713135614.1618183-1-yeoreum.yun@arm.com> <20260713135614.1618183-3-yeoreum.yun@arm.com> <20260714143450.61a94085@pumpkin> Subject: Re: [RFC PATCH 02/34] ARM: mm: make 2-level pgd_t a scalar Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, Jul 14, 2026, at 15:34, David Laight wrote: > On Tue, 14 Jul 2026 13:55:18 +0200 > "Arnd Bergmann" wrote: >> > I see the compiler has an awkward time returning a u64 struct (see >> > https://godbolt.org/z/qejbv6j9a), but if this doesn't work maybe we should >> > get rid of the STRICT_MM_TYPECHECKS stuff? I seriously doubt anyone is >> > purposefully toggling it on for testing from time to time. >> >> As far as I can tell, the #ifdef was originally in i386 and >> got copied to all other architectures at the time, but was >> removed in linux-2.3.23 from the original copy when CONFIG_X86_PAE >> was introduced. > > For x86-32 the makefiles request 64bit structures be returned in registers > (at the same place regparm=3 is set - probably added at the same time > between 2.4 and 2.6). > > Note that arm32 can will return a 32bit struct in a register and > arm64 will return a 128bit struct in two registers. > > The only problem is returning a 64bit struct in 32bit mode. > > I'm sure this code is arm64 only. The file we are talking about is arch/arm/include/asm/pgtable-2level-types.h, which is definitely 32-bit only and force a 64-bit struct return on the stack. I checked some trivial tests that show that arm-linux-gnueabihf-gcc-16 also still produces badly optimized object code with structures passed by value, and will spill those to the stack for no apparent reason. clang handles those just fine as a pair of registers. For the 2-level page table, this only concerns pgd_t, which is rarely passed around or returned by value. The 3-level page table has a 64-bit pte_t, which means we probably won't want STRICT_MM_TYPECHECKS there. Arnd