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=-17.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 D351CC433B4 for ; Tue, 27 Apr 2021 09:05:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4000F613B3 for ; Tue, 27 Apr 2021 09:05:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4000F613B3 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 2EC8A6B0036; Tue, 27 Apr 2021 05:05:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C36A6B006E; Tue, 27 Apr 2021 05:05:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1650F6B0070; Tue, 27 Apr 2021 05:05:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0146.hostedemail.com [216.40.44.146]) by kanga.kvack.org (Postfix) with ESMTP id E93336B0036 for ; Tue, 27 Apr 2021 05:05:23 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 93B731DF0 for ; Tue, 27 Apr 2021 09:05:23 +0000 (UTC) X-FDA: 78077563326.26.89FE05A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf03.hostedemail.com (Postfix) with ESMTP id 98596C0007F6 for ; Tue, 27 Apr 2021 09:05:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619514322; 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=BcjMISn7V/DVN17pgvTQsJjmuRI26S5gt2Wqek6aFi4=; b=dHjstjCMkMfhEQCVLXaaGKhFboHazGGHyE2ZRlXfRB10KVSAx8lrLy7HjbxeQe7/8f+v6S qaNgLsIrRon0wxippoU8ULSaFQLXyBaATaX2QH0aLZXHG3G8RhsY5NIcSTBUhC/s/L8tRi UD8Vru0TrlBeyP6w7We1zKp6wfbhl6w= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-527-_Dph2erMN0CLhOkxx53NGA-1; Tue, 27 Apr 2021 05:05:20 -0400 X-MC-Unique: _Dph2erMN0CLhOkxx53NGA-1 Received: by mail-wm1-f72.google.com with SMTP id t7-20020a1cc3070000b029014131bbe82eso1913284wmf.3 for ; Tue, 27 Apr 2021 02:05:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=BcjMISn7V/DVN17pgvTQsJjmuRI26S5gt2Wqek6aFi4=; b=i+CSrvIeIFSfyLCo8+ZSSU2QKXxAlFe76pa/wsnw5QSwd7McS3Tkj4Fw0kNuyr68Zf grEYTzMVXMGvDqB8rAlt2qNNMcN7ujsiHvgmieRhZzITGXMAjthoVxSOHSatOz5l4Flz mOQsiyecVtNbb28reEGN+xRMXSNQNKr5j8STQbTNmSHMEPdNkWd+KW/MsVirCrUQ2Ku9 hFVLQTIpyCZCXupW9x5Y30Z9kGmfLtBOIhU4OnCid/Yy3Uy3a54zu12c8LX20MZ6We9F rEkRWQl5h/um8MxG4e0hhRVQ3CjTSVyCH5eH0VZMe4dGhx1dxjewI3NQZx7E92LyenOn T2ZA== X-Gm-Message-State: AOAM530X2NrZTIYM8ntg1yY1bUTgzfey1hqIXVnaqWrnMCHFO/UAUxU/ gfNSdhl0lqjhJQj6bUV1ZdEQnAzfEnmytamhfejJp0wytZIyqzuoBUz40Y+8KgjHH5tSbwNSNpK 8c9rc0nXz0dM= X-Received: by 2002:a5d:5141:: with SMTP id u1mr28151140wrt.207.1619514319178; Tue, 27 Apr 2021 02:05:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyqgxvydwTKfDMMf1+J0sldSQLjLwqRj7z342B9/MovDRGLgaf70ey0MXxd7bl4GOIiLYrLcg== X-Received: by 2002:a5d:5141:: with SMTP id u1mr28151110wrt.207.1619514318911; Tue, 27 Apr 2021 02:05:18 -0700 (PDT) Received: from ?IPv6:2003:d8:2f38:2400:62f4:c5fa:ba13:ac32? (p200300d82f38240062f4c5faba13ac32.dip0.t-ipconnect.de. [2003:d8:2f38:2400:62f4:c5fa:ba13:ac32]) by smtp.gmail.com with ESMTPSA id m67sm2204003wme.27.2021.04.27.02.05.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Apr 2021 02:05:18 -0700 (PDT) Subject: Re: [PATCH] mm/sparse: Fix flags overlap in section_mem_map To: Wang Wensheng , akpm@linux-foundation.org, osalvador@suse.de, dan.j.williams@intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: rui.xiang@huawei.com References: <20210427083019.110184-1-wangwensheng4@huawei.com> From: David Hildenbrand Organization: Red Hat Message-ID: Date: Tue, 27 Apr 2021 11:05:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210427083019.110184-1-wangwensheng4@huawei.com> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=david@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 98596C0007F6 X-Stat-Signature: 6tsacaqozs96nuwpkkwh5xinwc1u1tji Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf03; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=216.205.24.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619514317-111900 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: On 27.04.21 10:30, Wang Wensheng wrote: > The section_mem_map member of struct mem_section stores some flags and > the address of struct page array of the mem_section. > > Additionally the node id of the mem_section is stored during early boot, > where the struct page array has not been allocated. In other words, the > higher bits of section_mem_map are used for two purpose, and the node id > should be clear properly after the early boot. > > Currently the node id field is overlapped with the flag field and cannot > be clear properly. That overlapped bits would then be treated as > mem_section flags and may lead to unexpected side effects. > > Define SECTION_NID_SHIFT using order_base_2 to ensure that the node id > field always locates after flags field. That's why the overlap occurs - > forgetting to increase SECTION_NID_SHIFT when adding new mem_section > flag. > > Fixes: 326e1b8f83a4 ("mm/sparsemem: introduce a SECTION_IS_EARLY flag") > Signed-off-by: Wang Wensheng > --- > include/linux/mmzone.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > index 47946ce..b01694d 100644 > --- a/include/linux/mmzone.h > +++ b/include/linux/mmzone.h > @@ -1325,7 +1325,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 order_base_2(SECTION_MAP_LAST_BIT) > > static inline struct page *__section_mem_map_addr(struct mem_section *section) > { > Well, all sections around during boot that have an early NID are early ... so it's not an issue with SECTION_IS_EARLY, no? I mean, it's ugly, but not broken. But it's an issue with SECTION_TAINT_ZONE_DEVICE, AFAIKT. sparse_init_one_section() would leave the bit set if the nid happens to have that bit set (e.g., node 2,3). It's semi-broken then, because we force all pfn_to_online_page() through the slow path. That whole section flag setting code is fragile. -- Thanks, David / dhildenb