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 X-Spam-Level: X-Spam-Status: No, score=-20.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B4D9C07E9B for ; Tue, 6 Jul 2021 08:36:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1DED761998 for ; Tue, 6 Jul 2021 08:36:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1DED761998 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A64E86B0011; Tue, 6 Jul 2021 04:36:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A14546B0036; Tue, 6 Jul 2021 04:36:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 866BC6B005D; Tue, 6 Jul 2021 04:36:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0121.hostedemail.com [216.40.44.121]) by kanga.kvack.org (Postfix) with ESMTP id 5B8536B0011 for ; Tue, 6 Jul 2021 04:36:44 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id C74FC181CC1CA for ; Tue, 6 Jul 2021 08:36:43 +0000 (UTC) X-FDA: 78331507086.22.FA0CFB8 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf07.hostedemail.com (Postfix) with ESMTP id 37016100252B for ; Tue, 6 Jul 2021 08:36:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1625560602; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=I+o/40+uDBX2iOKWdhlGm7tGKv0Mm2UPpPu5LYL1H+A=; b=b0YkBI2AP8ILtGaPLsNFplUztsAO0guq4RvcdLIEpJXfd8ZNY9XFsaxb8wutYqJ5/UzDvu jhi+R/MHWtDSnmXhIyoax5f/apzEro+RMuxI7hFy/zY4OOamiZH/EYKUpXXANkVADtaO7e vWmFaqn67dt+nrcMlShxvXJIB48GsG4= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-486-RE1f5DmePhGLX13lZyHvWg-1; Tue, 06 Jul 2021 04:36:38 -0400 X-MC-Unique: RE1f5DmePhGLX13lZyHvWg-1 Received: by mail-wr1-f71.google.com with SMTP id u7-20020a5d46870000b029012786ba1bc9so6911664wrq.21 for ; Tue, 06 Jul 2021 01:36:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:organization:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=I+o/40+uDBX2iOKWdhlGm7tGKv0Mm2UPpPu5LYL1H+A=; b=YaG0H0kg0KNtIdy03k8I+ATHraZ9C/UCBfmE17d21aT4RWE47UwgjE5R1sKSK9q4VG c+Y2Xp0p74f5TdArcYcbkcLs7nPo8LMgT1rDbQeJW73We4ggLOe2ZY99c2EYPAG6JH9I 94KJ8vhjAdyqRSaIRp1WTUDBJn9b3zqGhZ8LIO8679o55TVz0LYp4+coM8Yc6rx1spFm c1BTGxf3XwL6slkS6O8z6AxoQ+vPJhTO5O5ANX0Cvs1LLY45gGsteSg2hgybfSbqoX8Z SIjhrK7yi4uHvBaa7Yjp2byHv1fGTFz63PNi7w2cpmsXl4s4PhHaIjuMotaHmNo6WLNq sxLw== X-Gm-Message-State: AOAM530eMhjZOp1h3LodbwRJpZve1pupam8TzJjljBuJnJ++NZK0ZzoS zwiS9x8bSxyoCVmhutLkhiWjgBX0af8KxoPvM9tIVE9YPcdvGdRh1yhC0i4CRqq6vIHcupNKpth aNXJ1uGLhYfU= X-Received: by 2002:a7b:c248:: with SMTP id b8mr3556971wmj.115.1625560597627; Tue, 06 Jul 2021 01:36:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw9aVQ/6Du46/3/qnkFqf8wfnSzoxzzRTCxmqtbBtP+gQXruHwL9l4IP6UPUp734N0NoMVg+A== X-Received: by 2002:a7b:c248:: with SMTP id b8mr3556948wmj.115.1625560597447; Tue, 06 Jul 2021 01:36:37 -0700 (PDT) Received: from ?IPv6:2003:d8:2f0a:7f00:fad7:3bc9:69d:31f? (p200300d82f0a7f00fad73bc9069d031f.dip0.t-ipconnect.de. [2003:d8:2f0a:7f00:fad7:3bc9:69d:31f]) by smtp.gmail.com with ESMTPSA id b8sm2161916wmb.20.2021.07.06.01.36.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jul 2021 01:36:37 -0700 (PDT) To: Naoya Horiguchi , Dan Williams Cc: =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= , Wang Wensheng , "akpm@linux-foundation.org" , "osalvador@suse.de" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "rui.xiang@huawei.com" , =?UTF-8?B?SEFHSU8gS0FaVUhJVE8o6JCp5bC+IOS4gOS7gSk=?= References: <20210427083019.110184-1-wangwensheng4@huawei.com> <20210623230939.GA2963480@hori.linux.bs1.fc.nec.co.jp> <20210628070601.GB418318@u2004> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH] mm/sparse: set SECTION_NID_SHIFT to 6 Message-ID: <10142860-06b2-df68-c283-64560f31fb44@redhat.com> Date: Tue, 6 Jul 2021 10:36:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210628070601.GB418318@u2004> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 37016100252B X-Stat-Signature: j4bph4kctuupptbqfk6nrofh9r3bpjdh Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=b0YkBI2A; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf07.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-HE-Tag: 1625560603-824598 Content-Transfer-Encoding: quoted-printable 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: > Sounds nice to me, so here's a patch. Could you review this? >=20 Hi, sorry for the late reply, I was on vacation. Please send it as a proper=20 stand-alone patch next time, such that it 1. won't get silently ignored by reviewers/maintainers within a thread 2. Can easily get picked up/tested Some minor comments below. > Thanks, > Naoya Horiguchi > --- > From a146c9f12ae8985c8985a5861330f7528cd14fe8 Mon Sep 17 00:00:00 2001 > From: Naoya Horiguchi > Date: Mon, 28 Jun 2021 15:50:37 +0900 > Subject: [PATCH] mm/sparse: set SECTION_NID_SHIFT to 6 >=20 > Hagio-san reported that crash utility can see bit 4 in section_mem_map > (SECTION_TAINT_ZONE_DEVICE) to be set, even if we do not use any > ZONE_DEVICE ilke pmem or HMM. This problem could break crash-related s/ilke/like/ > toolsets and/or other memory analysis tools. >=20 I'd rephrase this to "Having SECTION_TAINT_ZONE_DEVICE set for wrong=20 sections forces pfn_to_online_page() through the slow path, but doesn't=20 actually break the kernel. However, it can break crash-related toolsets." However, I am not sure why it actually breaks crash? crash would have to=20 implement the same slow-path check and would have to double-check the=20 sub-section present map. Then, it should just work like=20 pfn_to_online_page() and not have a real issue. What am I missing? > The root cause is that SECTION_NID_SHIFT is incorrectly set to 3, > while we use lower 5 bits for SECTION_* flags. So bit 3 and 4 can be > overlapped by sub-field for early NID, and bit 4 is unexpectedly set > on (for example) NUMA node id is 2 or 3. >=20 > To fix it, set SECTION_NID_SHIFT to 6 which is the minimum number of > available bits of section flag field. >=20 > [1]: https://github.com/crash-utility/crash/commit/0b5435e10161345cf713= ed447a155a611a1b408b [1] is never referenced >=20 > Fixes: 1f90a3477df3 ("mm: teach pfn_to_online_page() about ZONE_DEVICE = section collisions") > Cc: stable@vger.kernel.org # v5.12+ ^ I am not really convinced that this is a stable fix. It forces=20 something through the slow path, but the kernel itself is not broken, no? > Reported-by: Kazuhito Hagio > Suggested-by: Dan Williams > Signed-off-by: Naoya Horiguchi > --- > include/linux/mmzone.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) >=20 > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > index fcb535560028..d6aa2a196aeb 100644 > --- a/include/linux/mmzone.h > +++ b/include/linux/mmzone.h > @@ -1357,6 +1357,7 @@ extern size_t mem_section_usage_size(void); > * worst combination is powerpc with 256k pages, > * which results in PFN_SECTION_SHIFT equal 6. > * To sum it up, at least 6 bits are available. > + * SECTION_NID_SHIFT is set to 6 based on this fact. I'd drop that comment or rephrase to ("once this changes, don't forget=20 to adjust SECTION_NID_SHIFT") > */ > #define SECTION_MARKED_PRESENT (1UL<<0) > #define SECTION_HAS_MEM_MAP (1UL<<1) > @@ -1365,7 +1366,7 @@ extern size_t mem_section_usage_size(void); > #define SECTION_TAINT_ZONE_DEVICE (1UL<<4) > #define SECTION_MAP_LAST_BIT (1UL<<5) > #define SECTION_MAP_MASK (~(SECTION_MAP_LAST_BIT-1)) > -#define SECTION_NID_SHIFT 3 > +#define SECTION_NID_SHIFT 6 > =20 > static inline struct page *__section_mem_map_addr(struct mem_section = *section) > { >=20 Change itself looks correct to me. Acked-by: David Hildenbrand --=20 Thanks, David / dhildenb