Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp704048ybt; Wed, 24 Jun 2020 09:11:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyRlera+qRCESPdyc1Uk+Di7oBLTqUJQKyA4t2W4PvN5I1a+sWRphRYlX+o4IkfuhJW9cgG X-Received: by 2002:a17:906:c943:: with SMTP id fw3mr7455987ejb.55.1593015109766; Wed, 24 Jun 2020 09:11:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593015109; cv=none; d=google.com; s=arc-20160816; b=HvJWvOremMrTJ71G1kq7bA3HVuSdbfpoZ5s5wY2Y1YJHWl0yKPGerGJtH8HulDfN1G GA50TXp8VFTPzLeoUj753QmcwBF770H2NZO8R0PCTfOmexUpynK78ueR3II3OkmuBK4K 7HMVGG33zj560jfMAq3a/Ox+kp99Ml1r/BlcBcXS2iu9trKx2Sl5FPeeLw4/q7bIdC4z 6BrOHxBVLhAFupqaVxP+1Isr4HUR8oQ8BakqRGUF68CEU2EDdpVU5Sqxi/Q/9lVGLBIt 3CTLoZer0iRKDzFiju3eguNkqaU9unO7H5ZdMAEpe584ZJbA4mgTfm9b9u5FR5McaU6N pW0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=CLPAvbq/jeYHfg7FTd3eSHmjKk2usdkzJKthmaiXIo8=; b=zuBynjeptqqhU9E1yO+DAuyuiJNQDcH/ARq5rkpgUMyVZNbfVlgKVcXiaU4hCsjwt7 EIUywdfBEJOtBgZi3pRSsBVl8If/Qcs+wK2XGE0CKhVWJgaW5hlQqox+ENI/Uf4hyuob sJPtPG72upFI5q76SsqJIi1nkeVUJlesIHDwF7vzQtG6RoXfI3VPikvL1AfMHuLvzbSw go3WRD2PTwr+EFWnsaUGMN/oOh6quklecxsMt5YGCrP9dA+wcfNqKv9+ppGAUo2BazbJ iED38m8m79xEJpE49Vp5bb71NL1MtZYDzbCWLut3caQ8kp7B5+sxljKrYBCLSBYLHrad mXMQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=ZvrfzlZN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id mj14si13225357ejb.464.2020.06.24.09.11.24; Wed, 24 Jun 2020 09:11:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=ZvrfzlZN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404699AbgFXQKX (ORCPT + 99 others); Wed, 24 Jun 2020 12:10:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38084 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404531AbgFXQKW (ORCPT ); Wed, 24 Jun 2020 12:10:22 -0400 Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40D95C061573 for ; Wed, 24 Jun 2020 09:10:22 -0700 (PDT) Received: by mail-ed1-x542.google.com with SMTP id t21so1891404edr.12 for ; Wed, 24 Jun 2020 09:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CLPAvbq/jeYHfg7FTd3eSHmjKk2usdkzJKthmaiXIo8=; b=ZvrfzlZNgIA+onZZAlqnmU1RPQNYcGK0AJ0sANVmYurFnqexDQH84xBGPSwIkrakti mFQTbpuFJLke0gP1+xA5KoTwMuBxllumFrO7SqUu7X5FbglbrRJSI8HZ0yMFxhrMW6ar hi4cCFCRjEbaQ9fgYypDD5zHzqbcn0rHcYB2PtRsFQCaCSitzwliPwcdRylK3Z2TTrE2 TsKVqQvMjx2bIBF1IjVF9LhxdzjilJqgWgKhWHw1G/fBrlUf8iqS8LGXH+47xrpc5/td cl2EnMSeaqZcjzoH+XVvN+XSUXjbBSqJZUQ16uvQv5ewo9CPxMVhN5yJPTHQAPxDLsrv Hgdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CLPAvbq/jeYHfg7FTd3eSHmjKk2usdkzJKthmaiXIo8=; b=er1xsQ38XRe5Ld6iNVf7PrZgzSjFTain3qlqvaJ/gvLgT7PSnT6Fas3ictVcvVSi1M RPb0TSDY9Mh3YgfnVI4hdFnLkGyanfRuXfS3O9AA2ZNfaLZJnVovbEX9Ui3QEvn/rolA xaB3I+MPe0GfxeCfM1ay32tHN+CNBiW1PgyXLczKxN3LqRcBQR66375r/amq6BOwaCEM vYE9D3m3ZkjSnsUlLaDXgwLZ4VgYOSz3zTjywo9eSxgUMxqOrdOGAo3rv4tG8xIiUlJ7 GK0VOAEY+hHZqT88DQFqcDaAflIYMhAeaQiPV3hib8epZwgCXioEedusgpe7Uhr/uQEZ Xu+A== X-Gm-Message-State: AOAM533rNQDlkaG7Rwy2Jssan/mUIMsDFo0b8FFB6sRn9Ux+XMlIH3yM 8pQtR8j7SKh8PhWxWNm5uVho3lPNeNG0d6NZyOB24g== X-Received: by 2002:aa7:d043:: with SMTP id n3mr3899927edo.102.1593015020879; Wed, 24 Jun 2020 09:10:20 -0700 (PDT) MIME-Version: 1.0 References: <20200623094258.6705-1-richard.weiyang@linux.alibaba.com> <20200623151828.GA31426@dhcp22.suse.cz> <20200624061340.GA11552@L-31X9LVDL-1304.local> In-Reply-To: <20200624061340.GA11552@L-31X9LVDL-1304.local> From: Dan Williams Date: Wed, 24 Jun 2020 09:10:09 -0700 Message-ID: Subject: Re: [PATCH] mm/spase: never partially remove memmap for early section To: Wei Yang Cc: Michal Hocko , Andrew Morton , Oscar Salvador , Linux MM , Baoquan He , Linux Kernel Mailing List , David Hildenbrand Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 23, 2020 at 11:14 PM Wei Yang wrote: > > On Tue, Jun 23, 2020 at 05:18:28PM +0200, Michal Hocko wrote: > >On Tue 23-06-20 17:42:58, Wei Yang wrote: > >> For early sections, we assumes its memmap will never be partially > >> removed. But current behavior breaks this. > >> > >> Let's correct it. > >> > >> Fixes: ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug") > >> Signed-off-by: Wei Yang > > > >Can a user trigger this or is this a theoretical bug? > > Let me rewrite the changelog a little. Look forward any comments. > > For early sections, its memmap is handled specially even sub-section is > enabled. The memmap could only be populated as a whole. > > Quoted from the comment of section_activate(): > > * The early init code does not consider partially populated > * initial sections, it simply assumes that memory will never be > * referenced. If we hot-add memory into such a section then we > * do not need to populate the memmap and can simply reuse what > * is already there. > > While current section_deactivate() breaks this rule. When hot-remove a > sub-section, section_deactivate() would depopulate its memmap. The > consequence is if we hot-add this subsection again, its memmap never get > proper populated. Ok, forgive the latency as re-fetched this logic into my mental cache. So what I was remembering was the initial state of the code that special cased early sections, and that still seems to be the case in pfn_valid(). IIRC early_sections / bootmem are blocked from being removed entirely. Partial / subsection removals are ok.