Message ID | 20231106-virt-to-pfn-fix-ppc-v1-1-93197a7ccab4@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:8f47:0:b0:403:3b70:6f57 with SMTP id j7csp2664358vqu; Mon, 6 Nov 2023 05:44:47 -0800 (PST) X-Google-Smtp-Source: AGHT+IGZ7++t3xlSX+IRNcHMhLdY+moHwdu9zkQGA+EUEeIefIfs+mwjh60szFSIHU334q/HTOqd X-Received: by 2002:a05:6a21:66c7:b0:184:3233:67a6 with SMTP id ze7-20020a056a2166c700b00184323367a6mr2634350pzb.40.1699278287130; Mon, 06 Nov 2023 05:44:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699278287; cv=none; d=google.com; s=arc-20160816; b=UnmmUUOhfbGAoG0P5tI0J+H3r4Fa/0RwfKxUChTHNXqNRl8FlI9l2+ceMSRTdaMlpL DLhnpsi6ol02Czy5cEGuq8TGEyUo/PFoavh25reDMlKuG/CdN9HIqo+JBq2Z5ZzDKyAA 1Mqp658Dlnc8BZ5AKCwBsaykRIUuK3JT8zMNqByk0HV0JyG2RvuT4ZrMKhLDMMD+UPAf dZRq73d6eqacmBSPO1XSMnW1N1dQMLsFw/jdRDLStjOarAE/bPswcTjzyd+XI4G5rGHs 9Iia+oFMzqULh2NrRrO4haDFCOiAuXIPdADYUGCpbVMVst5f9jfu7ehg5vvpt0pbGaeN W20g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:message-id:content-transfer-encoding :mime-version:subject:date:from:dkim-signature; bh=zfut42GZ6PJsX7RslNyzOoo+yrwpRsBHvP3u/FnXLmg=; fh=SJuOTFhQxMO17GCuOeEu0YyFK4F66VD3WqSU1tkTFw4=; b=D1s2nfVRrSvul0AeLRhOs9n+6Rczmmsg3fFss/BTHL372a82Q+L+XQbhhLl/qp0KHj 7DoF9eb9jyMiWo1CPDjpF9G/RdWNObXolIrYFM+lEMJRnWvppGEMa5jpA9GsunRRB+Jv Tw2SRBGCx3Dn6zcCZcZr9HUyaxcgnkoDkeh9TyJk5J0djWMsvvB3d+u3TJnlkFEK4f6R S3zF4uaUAagA2C4n6AAu6yAuPA2fdsDjkHs/BRULIqWrFg/kyqzLtbtI+ZaqS3LXPblz cF5qcPzV0MAT45vlr3Ex5QAldSStWuaWNIHF0IwYW5jsnVtChUpIENLsYaNBVdqlK+q4 U3Rg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=t3B7QSlm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id q13-20020a170902dacd00b001c9dfd47959si8702090plx.602.2023.11.06.05.44.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Nov 2023 05:44:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=t3B7QSlm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id B164880AD501; Mon, 6 Nov 2023 05:44:44 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232766AbjKFNoc (ORCPT <rfc822;jaysivo@gmail.com> + 35 others); Mon, 6 Nov 2023 08:44:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44188 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230192AbjKFNob (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 6 Nov 2023 08:44:31 -0500 Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 46CFCDB for <linux-kernel@vger.kernel.org>; Mon, 6 Nov 2023 05:44:28 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-507cd62472dso5950702e87.0 for <linux-kernel@vger.kernel.org>; Mon, 06 Nov 2023 05:44:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1699278266; x=1699883066; darn=vger.kernel.org; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:from:to:cc:subject:date:message-id:reply-to; bh=zfut42GZ6PJsX7RslNyzOoo+yrwpRsBHvP3u/FnXLmg=; b=t3B7QSlmEjUv1A8FdwtPvgaD+7A6NsRDq/Z660xex7MQKIAlH5rLndQ1QV5vruG6Y0 klKrwzuSzEKRUji7Dv7+8yddwCdwN5ScPSDUdPHeTEz8ADG0RWDe79jPEjmiyuYF2Ew4 eZWjtS0MKBVBVwvI5yUhCsrHBhPkpoXS5rLKv6VW3tJLinfL1h2HERyUCapXkNQCaS5I sfFJLhPS83dJdYLFPYXj+Dm8ELXsctNIFeY4ECbuWE+8QH53h0SPATKTdm/VdHFwpK1Q cpTiZsmcigHoA4v7WZOnZS1HKG2fT11iYpI9G95WICOsUkT94/KZBBmArQJgN1p8mvsy ewOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699278266; x=1699883066; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zfut42GZ6PJsX7RslNyzOoo+yrwpRsBHvP3u/FnXLmg=; b=Z4sEiR/3dPQQ2eX3jiaBPx+xAbgMOAzOwcAXs87Vrnssnd2nfU9N2Y4dCdcXvNiPJ4 xKNcSFpBm+Mtbx5bwXqI9Zzvb4EMdofrc57zzJAuaJUAeQidYU1Ddk1nTBRAlQrgw1IL NS6ce6IJLqeqbY9Xxt2oPcMFQsIkBgQ2nt9Re23rWbQAN4m03EVcbeWkJLgxKNcTzKAu E0ca3Ro1KlsiWwIKhfFWMILIYrdQtUb/RtgrDkbUmjYVEXMCKtUsQ9elgamryXpEei+Y zba7lGAwyq+7GBHbb7jJDK74IQ4TjXg/QESCPg067vdr0xWaF0ftusOlIIkIgp1m3g5f t0qw== X-Gm-Message-State: AOJu0Yz2kPmiBSKi2GhVtPgP2ZQWteWepeP2FRTj6+RaoFTaRFMdLEBz SWcxxvlwR100ii+EvEEQ6qfqpg== X-Received: by 2002:a19:6505:0:b0:4fe:2815:8ba7 with SMTP id z5-20020a196505000000b004fe28158ba7mr3312316lfb.25.1699278266334; Mon, 06 Nov 2023 05:44:26 -0800 (PST) Received: from [127.0.1.1] ([85.235.12.238]) by smtp.gmail.com with ESMTPSA id w25-20020a19c519000000b004fe2de20d88sm1123959lfe.232.2023.11.06.05.44.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Nov 2023 05:44:25 -0800 (PST) From: Linus Walleij <linus.walleij@linaro.org> Date: Mon, 06 Nov 2023 14:44:25 +0100 Subject: [PATCH] powerpc: Fix signature of pfn_to_kaddr() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20231106-virt-to-pfn-fix-ppc-v1-1-93197a7ccab4@linaro.org> X-B4-Tracking: v=1; b=H4sIALjtSGUC/x2MQQqAIBAAvxJ7bsG1UOor0SF0q72YaEgg/T3pO AwzFTIn4QxzVyFxkSxXaEB9B+7cwsEovjFopQciZbBIuvG+MO4Bd3kwRod+Is+jdUaRhVbGxE3 912V93w8BGl8jZQAAAA== To: Michael Ellerman <mpe@ellerman.id.au>, Nicholas Piggin <npiggin@gmail.com>, Christophe Leroy <christophe.leroy@csgroup.eu> Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, kernel test robot <lkp@intel.com>, Linus Walleij <linus.walleij@linaro.org> X-Mailer: b4 0.12.4 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Mon, 06 Nov 2023 05:44:44 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781822429144872668 X-GMAIL-MSGID: 1781822429144872668 |
Series |
powerpc: Fix signature of pfn_to_kaddr()
|
|
Commit Message
Linus Walleij
Nov. 6, 2023, 1:44 p.m. UTC
There is a const in the returned value from pfn_to_kaddr()
but there are consumers that want to modify the result
and the generic function pfn_to_virt() in <asm-generic/page.h>
does allow this, so let's relax this requirement and do not
make the returned value const.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202311061940.4pBrm44u-lkp@intel.com/
Fixes: 58b6fed89ab0 ("powerpc: Make virt_to_pfn() a static inline")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
The remaining warnings from the test robot appear a bit bogus.
If someone knows what to do about them, please help. The warnings
often properly uncovers problems that have been around forever
due to these functions being disguised as macros.
---
arch/powerpc/include/asm/page.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
base-commit: d2f51b3516dade79269ff45eae2a7668ae711b25
change-id: 20231106-virt-to-pfn-fix-ppc-d91de47c6017
Best regards,
Comments
Linus Walleij <linus.walleij@linaro.org> writes: > There is a const in the returned value from pfn_to_kaddr() > but there are consumers that want to modify the result > and the generic function pfn_to_virt() in <asm-generic/page.h> > does allow this, so let's relax this requirement and do not > make the returned value const. > > Reported-by: kernel test robot <lkp@intel.com> > Closes: https://lore.kernel.org/oe-kbuild-all/202311061940.4pBrm44u-lkp@intel.com/ I'm struggling to connect the removal of const with those bug reports. It looks like all those warnings are about 0xc000000000000000 being outside the range of unsigned long when building 32-bit. Is it the right bug report link? The current signature of: static inline const void *pfn_to_kaddr(unsigned long pfn) ... seems OK to me. It allows code like: const void *p = pfn_to_kaddr(pfn); p++; But errors for: const void *p = pfn_to_kaddr(pfn); unsigned long *q = p; *q = 0; error: initialization discards ‘const’ qualifier from pointer target type Having said that it looks like almost every caller of pfn_to_kaddr() casts the result to unsigned long, so possibly that would be the better return type in terms of the actual usage. Although that would conflict with __va() which returns void * :/ cheers
On Tue, Nov 7, 2023 at 6:57 AM Michael Ellerman <mpe@ellerman.id.au> wrote: > I'm struggling to connect the removal of const with those bug reports. > It looks like all those warnings are about 0xc000000000000000 being > outside the range of unsigned long when building 32-bit. Aha right. I wonder what actually causes that. > Is it the right bug report link? Yeah I'm just bad at understanding these reports. > The current signature of: > > static inline const void *pfn_to_kaddr(unsigned long pfn) ... > > seems OK to me. OK then, drop this patch. Yours, Linus Walleij
Le 07/11/2023 à 06:57, Michael Ellerman a écrit : > Linus Walleij <linus.walleij@linaro.org> writes: >> There is a const in the returned value from pfn_to_kaddr() >> but there are consumers that want to modify the result >> and the generic function pfn_to_virt() in <asm-generic/page.h> >> does allow this, so let's relax this requirement and do not >> make the returned value const. >> >> Reported-by: kernel test robot <lkp@intel.com> >> Closes: https://lore.kernel.org/oe-kbuild-all/202311061940.4pBrm44u-lkp@intel.com/ > > I'm struggling to connect the removal of const with those bug reports. > It looks like all those warnings are about 0xc000000000000000 being > outside the range of unsigned long when building 32-bit. > > Is it the right bug report link? > > The current signature of: > > static inline const void *pfn_to_kaddr(unsigned long pfn) ... > > seems OK to me. > > It allows code like: > > const void *p = pfn_to_kaddr(pfn); > p++; > > But errors for: > > const void *p = pfn_to_kaddr(pfn); > unsigned long *q = p; > *q = 0; > > error: initialization discards ‘const’ qualifier from pointer target type > > > Having said that it looks like almost every caller of pfn_to_kaddr() > casts the result to unsigned long, so possibly that would be the better > return type in terms of the actual usage. Although that would conflict > with __va() which returns void * :/ I think the return type is right, and callers should be fixed to avoid the cast to unsigned long. As an exemple, the only core generic caller is kasan, with the following: start_kaddr = (unsigned long)pfn_to_kaddr(mem_data->start_pfn); shadow_start = (unsigned long)kasan_mem_to_shadow((void *)start_kaddr); ... if (WARN_ON(mem_data->nr_pages % KASAN_GRANULE_SIZE) || WARN_ON(start_kaddr % KASAN_MEMORY_PER_SHADOW_PAGE)) return NOTIFY_BAD; I think start_kaddr should be declared as void* instead of unsigned_long, and the cast should only be performed inside the WARN_ON() In powerpc we have vmalloc_to_phys() with: return __pa(pfn_to_kaddr(pfn)) + offset_in_page(va); From my point of view that's the correct way to go, with no casts. Christophe
Linus Walleij <linus.walleij@linaro.org> writes: > On Tue, Nov 7, 2023 at 6:57 AM Michael Ellerman <mpe@ellerman.id.au> wrote: > >> I'm struggling to connect the removal of const with those bug reports. >> It looks like all those warnings are about 0xc000000000000000 being >> outside the range of unsigned long when building 32-bit. > > Aha right. I wonder what actually causes that. It is the 32-bit VDSO being built: VDSO32C arch/powerpc/kernel/vdso/vgettimeofday-32.o In file included from <built-in>:4: In file included from /home/michael/linux/lib/vdso/gettimeofday.c:5: In file included from ../include/vdso/datapage.h:137: In file included from ../arch/powerpc/include/asm/vdso/gettimeofday.h:7: ../arch/powerpc/include/asm/page.h:230:9: warning: result of comparison of constant 13835058055282163712 with expression of type 'unsigned long' is always true [-Wtautological-constant-out-of-range-compare] 230 | return __pa(kaddr) >> PAGE_SHIFT; | ^~~~~~~~~~~ ../arch/powerpc/include/asm/page.h:217:37: note: expanded from macro '__pa' 217 | VIRTUAL_WARN_ON((unsigned long)(x) < PAGE_OFFSET); \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ ../arch/powerpc/include/asm/page.h:202:73: note: expanded from macro 'VIRTUAL_WARN_ON' 202 | #define VIRTUAL_WARN_ON(x) WARN_ON(IS_ENABLED(CONFIG_DEBUG_VIRTUAL) && (x)) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~ ../arch/powerpc/include/asm/bug.h:88:25: note: expanded from macro 'WARN_ON' 88 | int __ret_warn_on = !!(x); \ | ^ Which is a bit of a frankenstein, because we're building 32-bit VDSO code for a 64-bit kernel, and using some of the kernel headers for that. So the warning is correct, we are doing a tautological comparison. Except that we're not actually using that code in the VDSO, it's just included in the VDSO because it needs PAGE_SHIFT. Anyway none of that is your fault, you just had the misfortune of touching page.h :) I think I see a way to clean it up. Will send a patch. cheers
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h index e5fcc79b5bfb..5243e48dc13a 100644 --- a/arch/powerpc/include/asm/page.h +++ b/arch/powerpc/include/asm/page.h @@ -230,7 +230,7 @@ static inline unsigned long virt_to_pfn(const void *kaddr) return __pa(kaddr) >> PAGE_SHIFT; } -static inline const void *pfn_to_kaddr(unsigned long pfn) +static inline void *pfn_to_kaddr(unsigned long pfn) { return __va(pfn << PAGE_SHIFT); }