Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2235382pxp; Mon, 7 Mar 2022 10:59:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJyPbGYkZ382tRQXiW49JoaPdE/wMoqrmWyM27FANsYlPIiB02u2paCI58LZTn80CkURbZm6 X-Received: by 2002:a17:906:39da:b0:6cf:7f09:a7bc with SMTP id i26-20020a17090639da00b006cf7f09a7bcmr10637877eje.457.1646679598541; Mon, 07 Mar 2022 10:59:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646679598; cv=none; d=google.com; s=arc-20160816; b=Tdf4T4VfQWz7uscJhnWRaLtojB0R0CAigbAjx5lS9J0kHW6rCAKQOntFz0KDZyltd6 Qoq7UDNnL1P3VV0RN18+8O97Puo3EWM6KMIDVeandA/9zW8AAIrA5N0SmcvSysItd8xl bdZqHE+MAqNrHcSRE6zOBglydmfmNViWH8VHfCzqQblc3qGKDmPhzp5AmdlKkBzgxyEO VRGtN4dj0O3W9HJ4EGEU0aBACTE/onsZCP3hfh9b2l5nmSRdAhjVLL8XIAtxvCi/Iq5/ xyqqeO1FFTuauO1P1TOnIR/rykYrkytvqInLsGb7CHxE5CXjdtOI9rVzUSzW2mSm6CY5 M8+A== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=qW5FPsjHoeDJhXjcnei9BSeHnfSk9h1jeGzbOieqiTI=; b=oWy9hOC5fAlZpzWtSOHDAEydw8dL80g0LPiPckEp8DY5T66fEgnbRFhRX7joy1PUDA LpWr5oEyhRPRuWiqiNUD+Pb78uZbhawUJ/0eVzv8wtWI+fZUdsPrsFq9P7nXVNs1MHER X4wR+0s6oxDWgbOKckfh0ugpyx+jxI+bOfPvjCkIBTubXLkypWcWzzq5Za+DlOxJRtTD kgHW0zlLZ3E62C6CM8fLa8W/DqaJMpjicANxoglkphR+l+2hD6C2hr+NREkBkZuSVkBF myEXwQL1X5+obJOB+tR14joFaiyQ1y2yww8UIxT5V03FXR05tTRCVvxEYicTQ9BnlaIO nSzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=Mvh1dUO5; 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 g10-20020a056402424a00b004138ef37518si9557885edb.208.2022.03.07.10.59.35; Mon, 07 Mar 2022 10:59:58 -0800 (PST) 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=Mvh1dUO5; 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 S242764AbiCGNJh (ORCPT + 99 others); Mon, 7 Mar 2022 08:09:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39276 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242757AbiCGNJg (ORCPT ); Mon, 7 Mar 2022 08:09:36 -0500 Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C648560CD2 for ; Mon, 7 Mar 2022 05:08:41 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id w4so3331540ply.13 for ; Mon, 07 Mar 2022 05:08:41 -0800 (PST) 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:in-reply-to:references :mime-version:content-transfer-encoding; bh=qW5FPsjHoeDJhXjcnei9BSeHnfSk9h1jeGzbOieqiTI=; b=Mvh1dUO5XlJTKhAQPXB10OJdy5tionKj/pcUVRBSYgQQ2XYHy1Iz09aVnM8gn13pbT EfWrBCO54EEaP743f2KxxiJxmO91AS90PxkE59Tm8IdWJ1VeUXxxzDAPZfqa0FVIc5Kt E48Otybo5+HsZ+bTexjnn3sjO7EI1uLgscUPFpnxC98gu8EFOrOCo+vHgSG6mim7+FPZ 6KDalI6lStC0WZ/nnCrs4/DiFH01Lk+MJJU5LBOZuZSZ2VN3VuTONhCzoLfC5gplBR9s Q7DcsNwsG2ebV7Fq/XznHUuizt6xizgYcLLBn8LXpctNu2/4P+BUymdiQJIwo5i6zsof 3D2Q== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=qW5FPsjHoeDJhXjcnei9BSeHnfSk9h1jeGzbOieqiTI=; b=c6j9mtvGEwHA1HKp/rmJH4yZO1QP+8vmIu9drjmN6/Bl3mDEEJTmUiavydZnnI4CaI VSP/8sQKKG3G+7wAdCw/QPbe7IcrkCAZsvbSq/wdtQuGGSI8W5ohbKkZTYxUW1k2izOJ X5cyC261lmkWI94seRmBO0WnmW7iT3kRvnnzCNAvuwrhSoMRLZayxCJYddCDU8tFqyWb V8UlARzM+fQ5+vAVhRJsvgnAUYiQnrlTkPxTMcTO2QNCBmNWh42UN5cGxUSPGO+mhQvv CyrBRjIePqnI2Y+X9uPH1/2xblHpcFPRUftzEP9Yk/87i88urBXGIzHTr/vkj9Fzfq/Z PBeA== X-Gm-Message-State: AOAM5338XYDPCezGAfMKol1n12lO2Ozenp+V4okYz2WbJvMs3mBpvZN+ uiQm1LWT87qgiTZXrJl8KfhiAA== X-Received: by 2002:a17:902:8bc2:b0:14d:6d13:a389 with SMTP id r2-20020a1709028bc200b0014d6d13a389mr11944727plo.2.1646658521277; Mon, 07 Mar 2022 05:08:41 -0800 (PST) Received: from FVFYT0MHHV2J.bytedance.net ([139.177.225.245]) by smtp.gmail.com with ESMTPSA id x9-20020aa79409000000b004f704d33ca0sm3258528pfo.136.2022.03.07.05.08.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Mar 2022 05:08:41 -0800 (PST) From: Muchun Song To: corbet@lwn.net, mike.kravetz@oracle.com, akpm@linux-foundation.org, mcgrof@kernel.org, keescook@chromium.org, yzaikin@google.com, osalvador@suse.de, david@redhat.com Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, duanxiongchun@bytedance.com, smuchun@gmail.com, Muchun Song Subject: [PATCH v3 1/4] mm: hugetlb: disable freeing vmemmap pages when struct page crosses page boundaries Date: Mon, 7 Mar 2022 21:07:05 +0800 Message-Id: <20220307130708.58771-2-songmuchun@bytedance.com> X-Mailer: git-send-email 2.32.0 (Apple Git-132) In-Reply-To: <20220307130708.58771-1-songmuchun@bytedance.com> References: <20220307130708.58771-1-songmuchun@bytedance.com> 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_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 If the size of "struct page" is not the power of two and this feature is enabled, then the vmemmap pages of HugeTLB will be corrupted after remapping (panic is about to happen in theory). But this only exists when !CONFIG_MEMCG && !CONFIG_SLUB on x86_64. However, it is not a conventional configuration nowadays. So it is not a real word issue, just the result of a code review. But we cannot prevent anyone from configuring that combined configure. This feature should be disable in this case to fix this issue. Signed-off-by: Muchun Song --- mm/hugetlb_vmemmap.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c index b3118dba0518..49bc7f845438 100644 --- a/mm/hugetlb_vmemmap.c +++ b/mm/hugetlb_vmemmap.c @@ -121,6 +121,18 @@ void __init hugetlb_vmemmap_init(struct hstate *h) if (!hugetlb_free_vmemmap_enabled()) return; + if (IS_ENABLED(CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON) && + !is_power_of_2(sizeof(struct page))) { + /* + * The hugetlb_free_vmemmap_enabled_key can be enabled when + * CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON. It should + * be disabled if "struct page" crosses page boundaries. + */ + pr_warn_once("cannot free vmemmap pages because \"struct page\" crosses page boundaries\n"); + static_branch_disable(&hugetlb_free_vmemmap_enabled_key); + return; + } + vmemmap_pages = (nr_pages * sizeof(struct page)) >> PAGE_SHIFT; /* * The head page is not to be freed to buddy allocator, the other tail -- 2.11.0