From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CB76446AF3D for ; Tue, 14 Jul 2026 13:34:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784036099; cv=none; b=jGrf4JrR0WXZFPoueqBkpZqUdm6N1NH40UHojZ/jtebW5F6IS22o01yynrPXurPNFpDTw3zs5ZBYlmXQhcbIq48+Z/uPdBHgJ/4mETbph4CN+F/5LVX3eKGWdG+wJ5elEGQvATZU55nQ8knRTH3zMDmjgksJcuNkinQx+krvLT4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784036099; c=relaxed/simple; bh=I2e1sTfNi+4/tdcSVWJfJEFTRfdPpzayG8ntKpiI6tk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=WDFPtNvwQokqF3dn4flb+lvV3oJQmEKI/OzdUjPdF+ubnZIxt+L7WHWS3GTZpRuh21IiYClXX7qm5v9WFHp7Fu+3cWWLxo89gHJLjP2oDza1jN62FRuMghPd4uWiBt0YT2FXIf5AaU4d84UeWh7S5R0wISakaiAFU3fTAGJDGL8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Pcmpa/oB; arc=none smtp.client-ip=209.85.221.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Pcmpa/oB" Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-47df6a5202bso2628483f8f.0 for ; Tue, 14 Jul 2026 06:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784036094; x=1784640894; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=+1tfMkiBqW2Fu1p0sa+0Qy+YQWqKnxqq1+cNEQovCl0=; b=Pcmpa/oBZFWZPe3JNn0cNNaOPOouKLZC5JPEHj5CX2faPXosrjjW3t7rtVaJSiqmAm IXrNWVOKptOFYG+vXZyTEg9ZaQkFyUAbwEEzpOz4XWHQKimvqS/6GzLen045TN3zy+ej xrZ1BQoVbzIYrptYHOI8ZoTXuZ33EHxGxd0gRZ/lnbVuZXUMxxmJdXsplQRnMSDlIu6R 3X7QIzL+JORUX2IQlxDBFPJk9U2s/WEn2GWgPv0teV4WDzqMHk57/tvivInes0PFTJ1p XUDb12v875PaxY7WT8v3abAtBDMV/jJBIZIw9nXckM2C70NHw4WUNq2mx+zQP6KIknse pwXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784036094; x=1784640894; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=+1tfMkiBqW2Fu1p0sa+0Qy+YQWqKnxqq1+cNEQovCl0=; b=pUx58KG3njdU8+Y/DMNoNEEklwuV4zyVIZV86lQZjdtJfKpFLSTHHVs06D8JABqIGm igc7IK957oO7/WfuU6p5vfEgO8lVNizgFBc/CzQ6zcrdW1qYvP+lhARXCLYyMHWjNzMG uBxk4WCVrnhUk9ononDCcQjmBFRHAlIo4SEpMJ0/5AMPK69u7vOQ6iR7sIodYUPxV8Zt SuKn265xzMZV9A9cfoefyzn+34/rRwn0DEcUa9UCPNQ+0SXLwdOXNWUrqX7ycISPXluK r+Wr/NsjsmBxz2lya+DPgbaUpLGf4Et4oJTQbZZG8ozEyEUHMvxN8K+W1OtOVX9A3YjP 0fyg== X-Forwarded-Encrypted: i=1; AHgh+Rp0rbUSij1Gn0cIHnWiKvkr53LM4jrQLkMc4H4jFwPaTHWgOvf8db2BHKEz12GtJeHpfxxtvt1MBOwJ@vger.kernel.org X-Gm-Message-State: AOJu0YyHrxDFEnPmqRJIdhxejmfK0my7Uo0IgyR4dRPy8j1YVQybSpPE iQ+qPNrXBtT4ehUc7S5TVoHTqXzRVH7jzkxrGF5KzFur2dC4cR6uHlaE X-Gm-Gg: AfdE7ckZ+yA/rLJ4E1/Ll4gRuteqQmFWa4E0nuvm7Cn61khvfuvtuMQFznpUaQlngJn 4ulG4KxZXrc7uwl/0ZtzffHAKsRPGC4Pj9xC1Csjw52jEigHEUC8FF48D43ivj0raEan/X2Tr+1 gHjo3/Ngmst9j4jrg/Mhi5nHrAFlbqo03FDRHEP9g3oWlwejke6BbEg8J7+0ItidgursFXXUgR2 ooJPUox4HuadAC7GrcpwU5kLQU1EnnCiju3AejqWHLKHfG9GbVWgDpihiQug9mPVmagjpHdQLWh b4YRN1HgGIsU/V8l+FmUUrT9t3f2cbFM58zvAvfV3wIi00x5QctH9ZIvn+WbakYAqdYhno4spXP aPcQ0wqmJPaM06kapBvhWSuspfOCBca7nfEvDkF0Eq/bMPXoJpAj8BQuKx+iD6HHwpTLyq9kyjp kpG7iPNyJyqU114oNh70J1cEp5ANIvarSDd96YYS0i0BCPhsAyncLbtUao6Ck3 X-Received: by 2002:a05:6000:26c7:b0:47d:f441:5f93 with SMTP id ffacd0b85a97d-47f2dcc02eemr15207624f8f.25.1784036093714; Tue, 14 Jul 2026 06:34:53 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f4635a63esm8687695f8f.9.2026.07.14.06.34.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2026 06:34:52 -0700 (PDT) Date: Tue, 14 Jul 2026 14:34:50 +0100 From: David Laight To: "Arnd Bergmann" 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" Subject: Re: [RFC PATCH 02/34] ARM: mm: make 2-level pgd_t a scalar Message-ID: <20260714143450.61a94085@pumpkin> In-Reply-To: References: <20260713135614.1618183-1-yeoreum.yun@arm.com> <20260713135614.1618183-3-yeoreum.yun@arm.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-arch@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 14 Jul 2026 13:55:18 +0200 "Arnd Bergmann" wrote: > 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 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. David > > 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 >