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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1EC6CC00144 for ; Mon, 1 Aug 2022 14:06:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AEBE16B0071; Mon, 1 Aug 2022 10:06:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A9AFF6B0072; Mon, 1 Aug 2022 10:06:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 962A36B0073; Mon, 1 Aug 2022 10:06:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 8A8F16B0071 for ; Mon, 1 Aug 2022 10:06:28 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 5C42D160ABB for ; Mon, 1 Aug 2022 14:06:28 +0000 (UTC) X-FDA: 79751198856.03.1908A9A Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com [209.85.128.180]) by imf02.hostedemail.com (Postfix) with ESMTP id E568A800FA for ; Mon, 1 Aug 2022 14:06:27 +0000 (UTC) Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-31f41584236so110018767b3.5 for ; Mon, 01 Aug 2022 07:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G5UhvGzRrQcBGCWtOdqFEgZwHRGSXUKRpcxRX6CD/7s=; b=rAPWjvDI2x1MNj7Bu1CCOyfybJSBeCkfp/LO5TNPavNuMm1PCpq9vZac1affXCfVvt HfQUD8IDa7FYkHaDZMmcJgTJksD4uPs0blDFqQ4TqvxFRHM8ukS10lHLa+Zyoq/SswML dFVjUkxMDEro74y/G2bBenIgy9dTvbXgFbkcc5PnIJ+4PHL3ocZEDki/xulKClATsVTa 8hSok7ks8K8ULZoPe5omstJhi8J3ZuM96/LSTUO/Sv9qL1U6a5psDTTSJObennoaI22A l4ANlFj4EZS+9RCDlPFPQfV+2r3BvdiPIQi/w8S3AYyLyMpIaQxPp6Uea92VnIcplfZ1 WoRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G5UhvGzRrQcBGCWtOdqFEgZwHRGSXUKRpcxRX6CD/7s=; b=Kd3nOxObioOtsjMbswZSTFRLdcWqcBnagzMjFNU5mQfJvLml9AoI+V12kMPKGROSa4 ZYwkzKOSTOahNNFmQk1+19Q8QgfqtEMexITaO94aNjyNPxIzWN3KW2ySsh/nkF4cKTW8 BiXbb71Pfg5CxiCFRZxcQB3XywfRJS0E1mT4SZvosuB03D6m9FWUwBsVGVteJ/3E1d7i 4uLsOfCAYBm/TzuVEJY4EzyAReKS/v+t4FYu40a147Sz2l793+WpO5kfQNDp4Vhs1zCG d9qttIigYr/pYOsCbwyQBzypiUO/PujeyJ9RTxl4Dx+MQ+slF7JMxdu7GPMoA9wCpyi5 hUJg== X-Gm-Message-State: ACgBeo1/n892HJAvepc/lqlW286PORAURxS4qH93I1rsA30Pij2/aM7u 55uh4Mu9b6S6loTAt0WlX0+WzNx0feIJFhwRuoe9DQ== X-Google-Smtp-Source: AA6agR6vW/VAc4Dmh2BSzM1CMV3dpkiThH+Yy3VeiFrVu6/wrlBxfsp4wfADdlQot0YVXYIc8OqwDm89KXSYApQ8LVE= X-Received: by 2002:a0d:f045:0:b0:324:55ec:6595 with SMTP id z66-20020a0df045000000b0032455ec6595mr11570098ywe.255.1659362787035; Mon, 01 Aug 2022 07:06:27 -0700 (PDT) MIME-Version: 1.0 References: <20220628113714.7792-1-yee.lee@mediatek.com> <20220628113714.7792-2-yee.lee@mediatek.com> <20220715163305.e70c8542d5e7d96c5fd87185@linux-foundation.org> <20220719161356.df8d7f6fc5414cc9cc7f8302@linux-foundation.org> In-Reply-To: From: Marco Elver Date: Mon, 1 Aug 2022 16:05:50 +0200 Message-ID: Subject: Re: [PATCH v2 1/1] mm: kfence: apply kmemleak_ignore_phys on early allocated pool To: Dave Hansen Cc: Andrew Morton , Geert Uytterhoeven , yee.lee@mediatek.com, Linux Kernel Mailing List , Catalin Marinas , Alexander Potapenko , Dmitry Vyukov , Matthias Brugger , "open list:KFENCE" , "open list:MEMORY MANAGEMENT" , "moderated list:ARM/Mediatek SoC support" , "moderated list:ARM/Mediatek SoC support" , Dave Hansen , "the arch/x86 maintainers" Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1659362788; a=rsa-sha256; cv=none; b=nkvetuD7iseWJL3iuEB9gbdeFa2b2kAQ6HMWvJ4YPr4V14juWPufNUe4g6lDoIcnAI2jsY SFVgVSAUfAJQVzLbt/EfY6+V4urzYZjGIjryp+6bR9y+AloNGhqEXlZiQHcYvoca9Umhkm 7j1tfiJB6ukJRkCq/353yKwi0H6G2pw= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=rAPWjvDI; spf=pass (imf02.hostedemail.com: domain of elver@google.com designates 209.85.128.180 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1659362788; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=G5UhvGzRrQcBGCWtOdqFEgZwHRGSXUKRpcxRX6CD/7s=; b=j38EQIaDdyoDtqGsBI0mj0Vt+g5F2HOOunasESgRqvVLNKOeOpBhSMqflWWO9Ndr2A2L1q KSZAoBYCIHvfrh2V4A53p+dsMgqxbIXsSiIrEqpcEiHehzvEa6oTh9HlqmJiaOgry2VZDg WXL3qyDNVww1CxOB22hqRVhEHliAoSI= X-Stat-Signature: birkaauwquhkt74nsqdh4t9hzs1kmxzf X-Rspamd-Queue-Id: E568A800FA X-Rspam-User: Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=rAPWjvDI; spf=pass (imf02.hostedemail.com: domain of elver@google.com designates 209.85.128.180 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam03 X-HE-Tag: 1659362787-99026 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: [+x86 maintainers ...] On Wed, 20 Jul 2022 at 01:22, Dave Hansen wrote: > On 7/19/22 16:13, Andrew Morton wrote: > > On Mon, 18 Jul 2022 16:26:25 +0200 Marco Elver wrote: > > > >> On Sat, 16 Jul 2022 at 20:43, Geert Uytterhoeven wrote: > >> [...] > >>>> - This patch has been accused of crashing the kernel: > >>>> > >>>> https://lkml.kernel.org/r/YsFeUHkrFTQ7T51Q@xsang-OptiPlex-9020 > >>>> > >>>> Do we think that report is bogus? > >>> I think all of this is highly architecture-specific... > >> The report can be reproduced on i386 with CONFIG_X86_PAE=y. But e.g. > >> mm/memblock.c:memblock_free() is also guilty of using __pa() on > >> previously memblock_alloc()'d addresses. Looking at the phys addr > >> before memblock_alloc() does virt_to_phys(), the result of __pa() > >> looks correct even on PAE, at least for the purpose of passing it on > >> to kmemleak(). So I don't know what that BUG_ON(slow_virt_to_phys() != > >> phys_addr) is supposed to tell us here. > >> > > It's only been nine years, so I'm sure Dave can remember why he added > > it ;) > > > > BUG_ON(slow_virt_to_phys((void *)x) != phys_addr); > > > > in arch/x86/mm/physaddr.c:__phys_addr(). > > I think I intended it to double check that the linear map is *actually* > a linear map for 'x'. Sure, we can use the "x - PAGE_OFFSET" shortcut, > but did it turn out to be actually accurate for the address it was handed? > > I'd be curious what the page tables actually say for the address that's > causing problems. test robot just reminded us again: https://lore.kernel.org/all/YufXncrWhJZH0ifB@xsang-OptiPlex-9020/T/#u Few things I noticed: * mm/memblock.c's memblock_free() also uses __pa() to convert back to physical address. Presumably that's also wrong. What should be used instead? * kmemleak happily converts phys_addr_t to unsigned long everywhere, but with i386 PAE, this will narrow a 64-bit address to a 32-bit address. Is that correct? Does kmemleak need a "depends on 64BIT || !PHYS_ADDR_T_64BIT"?