Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp2482455iog; Sun, 19 Jun 2022 19:37:51 -0700 (PDT) X-Google-Smtp-Source: AGRyM1t8qV0ULafoitsu1G1UQUvgYfJbNcAcGI9friapnd1c+HsIL+RbgOyM7oDuI8AoAz+N0A25 X-Received: by 2002:a17:90a:f991:b0:1ec:92c0:595 with SMTP id cq17-20020a17090af99100b001ec92c00595mr8853976pjb.145.1655692671580; Sun, 19 Jun 2022 19:37:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655692671; cv=none; d=google.com; s=arc-20160816; b=QyyF1LYBpJW2xioOlVtAq292ALZkaDx5KCtq7WQf9NWlEZVSwcyX3FiU/XBwlBlZ4h cObbfE5jV2Z7nt9I9zDkeiJfHeGjBL7A6a595+HKQBWPxXbBu7wUsH16n/K9CGwzIYLw +nzXyIBZCdewJjEZJRuPomcvpgkea+JnaJBX6lI5MhXZA6MIgL4JfZrGscNvH5CW0NwK OPcsu0srYz9ogb4sAe53m0V5txsE8o4ZH2dgYb4VkikjcQBVWuUXRfkTL6+Q0EARNIvs cZOCC+lEQE+fM6N0HALvgkKlCJbsld1sgJ5OT3rwzusNK+VhgMF8hl/MkWQ/s2BoFAhY UqxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=rKDkCWFLL2LKHrd0PY7oJwJSwDpD2T5oprcITiH4OoM=; b=E86DRg+Lu0sV4I6T5VqWZBRQChlQ6mEFwYJYZmEoF45xWvl06Fu/vO98xc2dqamDIe xiclEy+p6YI3GdR+nDX37eKPEk9jkaxzRAb+0e5G9J68KhZsqWKN5T/AL6BAgAowZeH/ iLvH6+08x1TYFQn+lMHNG0q3Ac+FDNPpwrVu17mL3Vnvi2x9FSNGDjFYNjnTzF4w6Vp9 62exqmyLiedxqet9DOrN3H6JrXsvPlefrQWxbuCLJaWNPut2D/0Sey8moyGe2aQbzH7G FZnJ0O1dLGa1s+8nx0YIQ6I7fJZzq3Bd0lXhLhiebLX4ezbTpgl3S7aAfSezx34hJZ9a H0LQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=caQjzPuB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g1-20020a635201000000b003fc52ba77desi13536479pgb.408.2022.06.19.19.37.38; Sun, 19 Jun 2022 19:37:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=caQjzPuB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233337AbiFTCal (ORCPT + 99 others); Sun, 19 Jun 2022 22:30:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34066 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232394AbiFTCaj (ORCPT ); Sun, 19 Jun 2022 22:30:39 -0400 Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C5C9EBC1D for ; Sun, 19 Jun 2022 19:30:38 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id o18so1449767plg.2 for ; Sun, 19 Jun 2022 19:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=rKDkCWFLL2LKHrd0PY7oJwJSwDpD2T5oprcITiH4OoM=; b=caQjzPuBIHwA2jjjyPgS+SZbXzK2In7vHfu7aUGNIa+U/C2FXhNA3dChQV+bWaMcPG 7FlS2gMLACmKgYIq4Cw1zTdb3dP+si8wWFZJujAs2+n4ZdWgXCl0slFlOChKYG/fm1Yo nNGpEcLHuSYfPWoKClGZYjMWL/nz6ACorgOwJ1+S7jXI9N/gEVwENiHOwo8Tib8PlyqS ikEj1dZ27MGpqnNJ+1u0cCNmGqLMim/wVupR6XNaTcBIr4LFLQXuOFrkKkoI2App6+OX oarEM0yWQdccJgOLK+o6cEp/LX/iKe+L3kccp6rOvoUVdwwN9mx11+k0RgFN0y9iDfu/ oTiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=rKDkCWFLL2LKHrd0PY7oJwJSwDpD2T5oprcITiH4OoM=; b=COXpFd+Vh6TJInUgYe6l8wmPwWLTKvrDVp3vd3LH35Ym/zDci6c7xuC2K+4A45lobP dFCosbwIKm8g2xwYBxDbfBlQehhRoSqoLhZ9wJ7vo185dBRMvGPjdILrUt2oc9hUE1rT JnNzeoJ63eqHXBjVWq4UIz+C8FWv2Ndh0gwBucUNzEcubiQ8ORrMaYta9IJbRIv+wGtN u78GqUGPOpvjCB+Igvyd/sRdJi/w4xbKcRz+rxpkKasjJO/9YCufUk8Co4ra+8nqFXnd nFRSigb4ikonBDxQ3tYQrMUei612Ixjt18ID+YcEGzsR1V46cMWaEVdYOTIcB8ZGFJ9h ErtQ== X-Gm-Message-State: AJIora9HJ1C0YBs7nx71DWztKefOKzz1N3diZAbnyz3TVjIvfpjx/HMH sjE6lLPbiSGRP6H0R4l8QCiUcg== X-Received: by 2002:a17:903:2291:b0:164:95f:b512 with SMTP id b17-20020a170903229100b00164095fb512mr21978303plh.120.1655692238298; Sun, 19 Jun 2022 19:30:38 -0700 (PDT) Received: from FVFYT0MHHV2J.bytedance.net ([139.177.225.255]) by smtp.gmail.com with ESMTPSA id z7-20020a17090a8b8700b001ecb29de3e4sm153644pjn.49.2022.06.19.19.30.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Jun 2022 19:30:38 -0700 (PDT) From: Muchun Song To: akpm@linux-foundation.org, mike.kravetz@oracle.com Cc: duanxiongchun@bytedance.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Muchun Song , stable@vger.kernel.org Subject: [PATCH] mm: sparsemem: fix missing higher order allocation splitting Date: Mon, 20 Jun 2022 10:30:19 +0800 Message-Id: <20220620023019.94257-1-songmuchun@bytedance.com> X-Mailer: git-send-email 2.32.1 (Apple Git-133) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Higher order allocations for vmemmap pages from buddy allocator must be able to be treated as indepdenent small pages as they can be freed individually by the caller. There is no problem for higher order vmemmap pages allocated at boot time since each individual small page will be initialized at boot time. However, it will be an issue for memory hotplug case since those higher order vmemmap pages are allocated from buddy allocator without initializing each individual small page's refcount. The system will panic in put_page_testzero() when CONFIG_DEBUG_VM is enabled if the vmemmap page is freed. Fixes: d8d55f5616cf ("mm: sparsemem: use page table lock to protect kernel pmd operations") Cc: Signed-off-by: Muchun Song --- mm/sparse-vmemmap.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c index 652f11a05749..ebb489fcf07c 100644 --- a/mm/sparse-vmemmap.c +++ b/mm/sparse-vmemmap.c @@ -78,6 +78,14 @@ static int __split_vmemmap_huge_pmd(pmd_t *pmd, unsigned long start) spin_lock(&init_mm.page_table_lock); if (likely(pmd_leaf(*pmd))) { + /* + * Higher order allocations from buddy allocator must be able to + * be treated as indepdenent small pages (as they can be freed + * individually). + */ + if (!PageReserved(page)) + split_page(page, get_order(PMD_SIZE)); + /* Make pte visible before pmd. See comment in pmd_install(). */ smp_wmb(); pmd_populate_kernel(&init_mm, pmd, pgtable); -- 2.11.0