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