From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (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 BBB8B46AEF1 for ; Tue, 14 Jul 2026 13:34:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784036098; cv=none; b=RU3QhBOi9f5QErw8PNVEPCKTCXnZqIlUO3398xVlsGmYtiWPCgXmIpFHz/9Wr2x1rE+pChUROUUyoooSDpWuLHnRKMOaAbdXYfPmWLB3XiX/bkHzPNkN9Ra4eb0SGU9CSFR3LGUuB4E5B4BYB7na2pTYCtm/Sz9wO3VCCiYxdmU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784036098; c=relaxed/simple; bh=I2e1sTfNi+4/tdcSVWJfJEFTRfdPpzayG8ntKpiI6tk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=n6j1OGyYtEI5VowDT60cgB7ZHQ8VGwOfn/kQRuIDgvEOXTaXerpZu30vxI7gvuXZ621brvWptcmA84YpjGF/EHclrDw/bCgKQAOqF/0C7xPCWjCsZ5zAQmlX4f55vZQIpI3iPBeV0e29kAxu/MyQbnDr1SarI6STGZjI7njJlY4= 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.45 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-f45.google.com with SMTP id ffacd0b85a97d-47df440fcd5so2406824f8f.3 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=JGEsdaulqXtRdsQRfGB+Ww1uFKnqhOqhvXILd3YpdWt4IP7aXaTP6p730ufISECwrO xco2IW8+mPr9UIjMSMxqmsOnVSTmOppIgnpjqQWdmjv85ulTMINn1grfc3VoHbGkjQ3R Esm29lP8u67wOSO4jJxp9xhNlHtW2ZRHAfKmh/ZzQnwpsyi1faJ46WXofll5RY152M87 5zSKHCX3GDJYaxdsno6TRa0B1gRZHd2MYeh/bkkQgek8537vSRS9RBp5/+HFn4fS/E2W SOJ7dfZaImRAYcqpEJowTBohIcsIXBGsOQW+9dQyE2FLuP4KMBpbuzvPaf920oKSnQ7t /FgQ== X-Forwarded-Encrypted: i=1; AHgh+Rq08LK5zUo3+QP6kvPsNrnxgN6tGWmDNaZeVKxNndurqZTe2f0VwoaeN043Pt2X3VstwNP+fVJdLyPtihK2bA==@vger.kernel.org X-Gm-Message-State: AOJu0YxfFsmkk1VcsaHWkyJ4+OVfgzUZ9Vs4Efum5RGLK3b+V5chWTLn 9ynrPQcSmVqcPFxyPLtiNWken/dwOd7ElwjhNXihGq6q5Zh6imp9CIhm X-Gm-Gg: AfdE7ckLJ8Sj5xsxfrQoLZp+o3MgM0b29rQH2F+ZGtmjxgFIp0NpdGwKSlPW7YmnRLI z+kIq8sfUDrGOgBzoXYlb72t6ELixNDEwrxjC0viKVB//iDEN3Hhp/L3uyaauspTRELBDXPJUI0 kohYoPRM4mW5IogERl9CyfcLZ/t9/rlgG969oRgsuTJ9h7VX+eWv10Y/87fkWsDUu4Rw042G9/Z tHCinqBDYINZXur/JCokkIy0bnuJugH3ioshhAxsCHU37Ib6z4BVj9EYFXMr4VuGKrHGY4Ee1xD i/Rvc+IYKcvId4hZfYkn/z8pgYu5nmJw73byIWPKmVUJRJieHwn2+U1SyvRNqzsws6AxzZGlLlu GN8hSssTFJdLQMsojd8yl7buMf3cS6hcLR7Ei2C23NX8yO1LeQmw1hVpQ3daLb7Qe9TpEG4VL4R cgoNvL7PhbgNyXJbohQfu59zqyJxBDiTkB4luJn74r7B+/FnmoYJoqGhhVcTGM 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-openrisc@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 > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EA6E6C44508 for ; Tue, 14 Jul 2026 13:35:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=M7Oaa40n+6kX97Wq3FgxYMSV0QkxXQfA93E9NiY1DpA=; b=U02RH8AXlpjYh6 +QxyQOt6Nix9d5l5F4btQQH9F/uStrfinrRUPRkZ1qQ4kOilMbpUCcIq0AHC+or6ffbQn0VIbSR0f ucAnVNkkT3RqH1R37pnU/zAiwQDknugMuxlBWS53FCeHxi2XA6+bitgU0P3s0kx0YSWMkJm+FZTph jSS3oBn86NEZ5emRCKFIq9w+cDEyWHXuNZo0IyFQRcEyoY1u5naUfLaf7aYgvv/XETt8VOcUB0xIb 8PhjRmAIoTEsnF/BnGnt0BtbvKhVui0UQp69fLThQ5DlIx2SZ9VvGdqxtPw+alUNKt/UBFgll7f9r eUGWCxEdrBG+dGGMATag==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjdHp-0000000CC1u-2P5J; Tue, 14 Jul 2026 13:35:01 +0000 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjdHj-0000000CByy-3aUa for kvm-riscv@lists.infradead.org; Tue, 14 Jul 2026 13:34:59 +0000 Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-47df6a5202bso2628489f8f.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=lists.infradead.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=b83yhHzBkmNluMoe0lPPjI/d+8OSnVmVDyEYo2+65aimu83rz+OJSfBQsNvqdMsdch LCcauAs1GyO1zcSIyZyww1sb3tuExI6/KQJl5sXk4OgRhdTprzIt//zcP00v0Dxb1id+ s7sxqtWLkntERpepb6eMohJoCdrMLZiH7XNWS24b1m684A+lYbnUE/z+BvJvKlkvRM4d z7rNACabpsO/yIBmYHY0HOywIdVoyfzIunbzAb7vIbu0BEwd5fbxwTI2YZyw+yVxxp/a 5Upj6vbaRLaQw0OauOmLOAs2WOtHnE29Ddgb5WrI7nDlCOjMop0gUHr6JVR4TD7NCtzR r1Ag== 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=G21EG0WCLNAMwU6TADLXWGtonw4WAU7XKA7svpsCybu3Orec2aTOyOaTD2Jr6D4Jmq +OxLy/VV88nF/4e0A5zdu3OyxFL2ij/0QFytpfIkKF6rxXZ4te4pxaj0Qk51HlapQQIS 8KPQLnL91/Iibpu+i3uY6FYfxaKiGEIy/5ITOAK/ZdfvIsYx1g8AKgE3B3xIIsTTWR3X Sjqba4MYgCiR0g58YhvWp/lx8OThFsrjOR9aqfVAaC8lkf86km7tbOv0A6/5FXqbMgVb KDsa5N5qJrYqwWK80QCJk0QFovvShnC++9pqsef3NGiMB8i1h9zKNysLrFRKgGroe7Mu vnvQ== X-Forwarded-Encrypted: i=1; AHgh+RqKz7NnEP01k/w4hAeD9yfj86wkfiYVlFbFUQCfWqgrxmjbt0O49wI3texGQeGebfABBFIdaKqXHl0=@lists.infradead.org X-Gm-Message-State: AOJu0Yx94xl3gsezRbAs3SYfX/40MvwxWyAglrGukpeY1Ege/9RjGBK1 g0ppUMCb2wScCcZ7jo70asJOEnRZ/aL2aQE2RL36ihxCs+jIhXylgteb X-Gm-Gg: AfdE7cmpPUh8VRmw8Vui3srVw3oZAu0u5dX2vbGxGGN6hXleB/MMPo6gKUYK06svbJE srkx+nv0fImvJ2pEe6ImqfEg2O0tfZkSX6EO6M+MRG679CMYfLyaxRB4WNMml0saWuR8MeuUUgI yLNP+fWjCdn2K9YFT7GDozp3Rf7YnCb5UnnNJeXXQZ+ZyTlllbvFY4+NY/qY/SvutBD2GnpzndU mbmc0LwVMubLWikTZECSelmPkB0kABck/Eldd0ih4Fc1PFtboIs0X+mOTYjYSwmCocvkPeWXPIB dEoL06gWMwYeKkVb1bc0OtG4gUocZFB6eUveknBUFadvFBs2C4QgX9yZr9rZ2FVjZN3mUe3Ubeh M1dCcUQhMlATJ1cnEwiXdU6UXH/wOQrsMjyhjngyPTef0nwW9eaArVfVNHLsHCf0Gtcc+AoczsB MOCUxpvAXbFgb/1ffZ7XCsRTUBRdKZwUr9HEHEfa6k9jV7p8R9t+iHknSNINE2 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) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260714_063456_006052_3A7FABB3 X-CRM114-Status: GOOD ( 36.38 ) X-BeenThere: kvm-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kvm-riscv" Errors-To: kvm-riscv-bounces+kvm-riscv=archiver.kernel.org@lists.infradead.org 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 > -- kvm-riscv mailing list kvm-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kvm-riscv From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 69883C43458 for ; Tue, 14 Jul 2026 13:35:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=/8M8c1ZaxiVzbi4J7Y737MoDFIzpD9EaLY0VWnWh75E=; b=chejpgiBjJjcbg ZrHBq5jtkSfyi/DgyuVZHlUMAnqSoJIudZOAuNMfuZwzqztNVOKIWAny47qPFSu+tS+Fe0UKXUGej Chz9obtIweZIdNIGgcWYrFU1f/JBIHpTNHVFURL7tZbfRA0G0uB247Tp9wC4s0G8RlrQ9xucydLUj v4WKDyg3htcQmyRbV8tL72CHRRruXpjy1E7OSXxbDmF/2bz6nmIPnXpIUg1dGWE55JvfWj9eobDzk JdmYl2LClLZnRLFbGe4DIK/uKxjpJfSnelsULquXV8XybEb8PHnfUauYLiYueVrCOCijpWK/DPZwr ADidVKmaCAg/BJRzXTvw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjdHp-0000000CC1j-1vRo; Tue, 14 Jul 2026 13:35:01 +0000 Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjdHj-0000000CBz0-3p6G for linux-riscv@lists.infradead.org; Tue, 14 Jul 2026 13:34:59 +0000 Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-47df440fcd5so2406832f8f.3 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=lists.infradead.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=b83yhHzBkmNluMoe0lPPjI/d+8OSnVmVDyEYo2+65aimu83rz+OJSfBQsNvqdMsdch LCcauAs1GyO1zcSIyZyww1sb3tuExI6/KQJl5sXk4OgRhdTprzIt//zcP00v0Dxb1id+ s7sxqtWLkntERpepb6eMohJoCdrMLZiH7XNWS24b1m684A+lYbnUE/z+BvJvKlkvRM4d z7rNACabpsO/yIBmYHY0HOywIdVoyfzIunbzAb7vIbu0BEwd5fbxwTI2YZyw+yVxxp/a 5Upj6vbaRLaQw0OauOmLOAs2WOtHnE29Ddgb5WrI7nDlCOjMop0gUHr6JVR4TD7NCtzR r1Ag== 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=dDMLBvul1/ACl138bYFbyCTNtSvslq3qM7rlleFWRGoJja2AOT/tLcpevRTy5ZJtLC +e5gx8RzWN6bPJal1xOcuXuui0pdtUna21TrJAwGyeeoIMz3X+8CcXP0ngInedVkhUDP ovIjYfl4tpdxURDF/Ojmkdw2LNxu9HhLJZLvBmaxp1zTxAUipMCRdLI5uH/qmn103ArP kfzCY4d8lONF5H4sdlrf7yoD0Of7YeASsud85733ezouqY/4TIp1Ad1nSxDUjMpd4aiY bys8ZhVqhtfCzjmSo++bdCji8ODCHVUZJc7wDCVfZ8ZmStoEnol+yTNnwSox9xqQhAge VvTA== X-Forwarded-Encrypted: i=1; AHgh+RoCddp5SGz3FMKAW7p05cL54AJsD94Y1BLruAat0ex8osqUQCqF0jIzO3z1MWzRIaXlxB3GPYRR9uWisQ==@lists.infradead.org X-Gm-Message-State: AOJu0YzBUbDHxHwa04eSXBhzXS/fD8XXTovLrCVJeSzAm+zA6Icz0hcd KhBTWmSJxbm0OmX/PFaiiwuuwMdfVWYBkN6S60fd9ETrz+K0NpC7bK1n X-Gm-Gg: AfdE7cmQMROFzzSGfidiCYglrlIxgUNa55zvKgr3vvVo2p3uTBzQoxo1MtMFRvosUDS MTeJe2yKAlUZlWycRLwLGzR/cesI43nMe3XgjhYicdOer9GWCFxpH9NQ/kozlD+5rLEUEg1ILiS 3vb0hfzfx9a5NkZMSPNtC2gY/3tqz2k0Dz1L9rLYACZOfsTClWrkKmgMtB3B198LZsy6iQ6icCS 2agJSdvXtcF6W4SMj9dCaWVzVd1I12BmPZpq5vWq0byvC7Az7jzSKiDd+FTsxj3xeFZltAb/koh 2jnpUXR9wkQn1h2C4luGXUgqYkhbFiOyJZiCHKvy3zSwsMXFbLH3DiUeeX6nb9QKfnOU3aDthPv V+algWwXF9S+MTcUZVaWZRa9onGK6eeol5HTxQA4sr2hozu2S5R6rjBPy9cKfBqm4L8E6xP74qC JggKbxwAlO4ko5qhQ2t4jsQ3YYWYtl5za7e8K7G+hT3yQwc4MYf/5kh5DDy7CF 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) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260714_063456_015055_82A2328B X-CRM114-Status: GOOD ( 36.38 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org 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 > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv