From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from flow-b7-smtp.messagingengine.com (flow-b7-smtp.messagingengine.com [202.12.124.142]) (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 C678C381B02; Tue, 14 Jul 2026 11:55:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.142 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784030148; cv=none; b=qFQhsXbqsKdKGkoJmIBQFf5PKnqrM97nvJ3GV6fmOT0fkajcrI/z786CKMN0pd5eue5vrrP1vfoawbcR5xvqXlM7P+UF+0fvcBNluNOEvSzLafbpcRMacdDAniqvHO9rD9xPXXPt7XaqI0HbMMCR3dWiNLs1mYOwM55cPa3gVmU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784030148; c=relaxed/simple; bh=hRL0oCdXaak28xm3obemws0bBwDNQCZN+5mYdmwkcE4=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=RIADG9WokXoicKPx1CRLpyCHb+RPW32znMjOpc3qiG3f9LyUZNn7TdAsHdTfEZNMLibQPCcuuQf8ioAwSsCHkMZ1v+JKi4w56oD1x+bIw+RM4I3+kfWeyRHuit801nMMxGYbw7R1VvHNGYOA65+gtfV5gyg7NSvBgj9yCwuYpb4= 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=CVv3c2hh; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=fNsAiUF2; arc=none smtp.client-ip=202.12.124.142 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="CVv3c2hh"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="fNsAiUF2" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailflow.stl.internal (Postfix) with ESMTP id EC16A130018B; Tue, 14 Jul 2026 07:55:43 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-04.internal (MEProxy); Tue, 14 Jul 2026 07:55:45 -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=1784030143; x=1784037343; bh=T+24MjkKOyccdIXKr6nivOOwP9jmSIAod++JgzQuHBc=; b= CVv3c2hhp8uDNc5r7ko2QUEtAAEx6nH7+CrFdGshtB/9AFtkXsk+/qw3yHVkZex3 Vu2pyZGe7H8X64Mc5ca+WSXsO7bWC9O09NZdEmA7HZE7eZ85HM3/1zLXggvYdeuM 16qF02oA9jL+4y2fpX6uD2YZuMPLGt0nMGRyEVu6f9MeJYOE+aR6E1lpqUGQowZ1 KP9Yq4MFqjRpWhYQBq12QjfuhTqbRZiaiTTMwnONYQKH0y2vq/r/elX57A31FF6N 1W3e3QWu1DoyiVFQBGIkueMbUdAh2ZnUSSYsL5UDCpUp3AC/zE/RYCulDhbLOw7k +uFvtuEOSR+bhu2NrvK7aA== 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=1784030143; x= 1784037343; bh=T+24MjkKOyccdIXKr6nivOOwP9jmSIAod++JgzQuHBc=; b=f NsAiUF2wwNHbm2aRh2VZvJga/CUIwB0EAlWxBskMLODdHCILE6vnzOvR83AnOzQl C8hVCO4GyTMsu7FBrFxQGuSWPsKy3FSWOq1c+xUKsYqBv4uEqrRFB3gayLttIqS2 u83K4SQN9y/BFFYAKEW6yjopRJxx9hQlgxhLko+W03RWXrYA4yXKm7O2ajDzwFFM e83tcetVh9XkdyXTnKRy2e8TO+K900r4hcchIyI+CPCM7XZqPq1GFTEy7UE4lIR0 J7HVETXUGSGEAo0czc6ylx+mDLI8TqprfL9KLguzXthnTGD0UsguRyqtmSV0VkT6 6aVmY5FL81d4cieO9JZ6A== X-ME-Sender: X-ME-Proxy-Cause: dmFkZTGxIX4qsR7V9UOAbbpZ7DI+TPioS3EdeOfkz2sqQrWFwCwBFa2jO13xOhfwAzebyL vDn4L3EOcKqRhgsBPy8K0LlhasC87RLvJKakFM63Ex5ajF1mW9HBfU9h64M01z8Zkd1enj GGlJ+S1uE0LE0ntEkqcD2W8Mc7+iLE1JAn9qBp8jOSHfQ/492DuvwwXjB3rPP8pj/tMaxq q5TAvzCpGhJ8fPEa4+CYMo9P46KZqjk/ruzcYSl9IYoSn7a13f67wJC/dG+TgSpdxoToXo rHMhANm1HxqVijJlmPefX4wiI6JZN4Z55MCfIh8k55OoUatB+dk0XUuzpv91MEhl04VWsV ZSok8TCuuKj8PWwP0EiIT6QCPzE9Rhj+56/WVYSuoFKN5pnvjixLDWFi+WaLep3dlBF/ZM R1gPJomvZP0vI1mZd2xbHjHC4PbZoDJZaTI2Ff/jkCigkrwZtlj8DSAfGjPYx0nC29U3Zy hDEvNQoI0Xi+DgnJGdxCmodO1+oDmF5qjsBDd7dKYUF5QBBYz+zfMf4uhbEhlzoLTu8U5r m8QjPMKAYeAQelZO7q1lnl3i66zJ6sB+Q3LY9jh3ODNPd2SBRx29u7BvyOPJFOnGnIoKbW izEG2Rtu653VGFVorcXYXHnVQAnHtxZF9aSmlvX/LNWUy3QkWR/KwJPtp2hw X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 57A521820082; Tue, 14 Jul 2026 07:55:39 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-csky@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: ASU80-mPZ9gg Date: Tue, 14 Jul 2026 13:55:18 +0200 From: "Arnd Bergmann" To: "Pedro Falcato" , "Yeoreum Yun" Cc: 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: References: <20260713135614.1618183-1-yeoreum.yun@arm.com> <20260713135614.1618183-3-yeoreum.yun@arm.com> 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 12:26, Pedro Falcato wrote: > On Mon, Jul 13, 2026 at 02:55:41PM +0100, Yeoreum Yun wrote: >> From: "David Hildenbrand (Arm)" >> >> We don't want pgd_t to be an array, as it prohibits returning it from a >> function, like pgdp_get(). >> >> So let's just use an u64, and extract the right 32bit value in >> pgd_val(). >> >> Leave the STRICT_MM_TYPECHECKS case alone for now. > > I have to ask: is there a good reason for the STRICT_MM_TYPECHECKS ifdef? > > 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 some reason, only sparc32 and arm32 still use the non-strict version, with arm having changed from the struct version in 2002: https://github.com/tbodt/linux-history/commit/5a8202f0259a https://archive.armlinux.org.uk/lurker/message/20020306.213958.cd486eeb.en.html > If STRICT_MM_TYPEDEFS's worse codegen doesn't matter then maybe we should > permanently toggle it on. This would definitely need good testing. It's possible that it's not that bad on modern EABI builds (i.e. everyone these days) as well as modern compilers, as OABI definitely had bigger problems with 64-bit arguments. >> +static inline pmdval_t pgd_val(pgd_t pgd) >> +{ >> + return (*(pmdval_t (*)[2])&pgd)[0]; > > Ugh. This isn't correct C code. It only works because the kernel passes > -fno-strict-aliasing. I think the bigger problem is the code dereferencing the pgd pointer in the first place: Since the pgd pair is written in 32-bit units in __pmd_populate(), anything reading it would technically have to operate on both entries. As the kernel relies on -fno-strict-aliasing, the type mismatch is less of a problem than actually doing the potentially wrong thing. As far as I can tell, we are however saved by pgd_val() only ever being used for debug prints, where printing the first entry is likely all that is needed to analyse the real bug. > I would recommend either forcing a struct here, or > using a u64 with bitmasks/shifts. That would require extra complexity for the big-endian case though. Arnd