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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 765F6C433EF for ; Fri, 29 Apr 2022 16:46:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379274AbiD2Qtt (ORCPT ); Fri, 29 Apr 2022 12:49:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34830 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378833AbiD2Qts (ORCPT ); Fri, 29 Apr 2022 12:49:48 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 96415A1456 for ; Fri, 29 Apr 2022 09:46:29 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 4C043B835F6 for ; Fri, 29 Apr 2022 16:46:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DD4A4C385A7; Fri, 29 Apr 2022 16:46:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1651250787; bh=vG9TgIsYv0olLF8Zc7F6jMU5RFb1WDEXwb1nhg33XRs=; h=Date:To:From:Subject:From; b=ZzZ0m5nws0cpkM1MFHtSVZ+4ZFEzd9SxhbbGhtkFClfD83cTaGyypSqDbt3rxUge9 n3vQbczMWxxtENnjwy0u85u1BEPrliN9jhSXpuNS7Xmjv9aO8PV10n+MrtUZxwd6O9 7iocIR9UONkh/dz9uoXtVQ18EktAHO+kHhPdIDn4= Date: Fri, 29 Apr 2022 09:46:26 -0700 To: mm-commits@vger.kernel.org, yzaikin@google.com, osalvador@suse.de, mike.kravetz@oracle.com, mcgrof@kernel.org, masahiroy@kernel.org, keescook@chromium.org, duanxiongchun@bytedance.com, david@redhat.com, corbet@lwn.net, songmuchun@bytedance.com, akpm@linux-foundation.org From: Andrew Morton Subject: + mm-hugetlb_vmemmap-disable-hugetlb_optimize_vmemmap-when-struct-page-crosses-page-boundaries.patch added to mm-unstable branch Message-Id: <20220429164626.DD4A4C385A7@smtp.kernel.org> Precedence: bulk Reply-To: linux-kernel@vger.kernel.org List-ID: X-Mailing-List: mm-commits@vger.kernel.org The patch titled Subject: mm: hugetlb_vmemmap: disable hugetlb_optimize_vmemmap when struct page crosses page boundaries has been added to the -mm mm-unstable branch. Its filename is mm-hugetlb_vmemmap-disable-hugetlb_optimize_vmemmap-when-struct-page-crosses-page-boundaries.patch This patch should soon appear in the mm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Muchun Song Subject: mm: hugetlb_vmemmap: disable hugetlb_optimize_vmemmap when struct page crosses page boundaries Patch series "add hugetlb_optimize_vmemmap sysctl", v9. This series aims to add hugetlb_optimize_vmemmap sysctl to enable or disable the feature of optimizing vmemmap pages associated with HugeTLB pages. This patch (of 4): If the size of "struct page" is not the power of two but with the feature of minimizing overhead of struct page associated with each HugeTLB 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 hugetlb_optimize_vmemmap should be disable in this case to fix this issue. Link: https://lkml.kernel.org/r/20220429121816.37541-1-songmuchun@bytedance.com Link: https://lkml.kernel.org/r/20220429121816.37541-2-songmuchun@bytedance.com Signed-off-by: Muchun Song Cc: Jonathan Corbet Cc: Mike Kravetz Cc: Luis Chamberlain Cc: Kees Cook Cc: Iurii Zaikin Cc: Oscar Salvador Cc: David Hildenbrand Cc: Masahiro Yamada Cc: Xiongchun Duan Signed-off-by: Andrew Morton --- mm/hugetlb_vmemmap.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- a/mm/hugetlb_vmemmap.c~mm-hugetlb_vmemmap-disable-hugetlb_optimize_vmemmap-when-struct-page-crosses-page-boundaries +++ a/mm/hugetlb_vmemmap.c @@ -28,12 +28,6 @@ EXPORT_SYMBOL(hugetlb_optimize_vmemmap_k static int __init hugetlb_vmemmap_early_param(char *buf) { - /* We cannot optimize if a "struct page" crosses page boundaries. */ - if (!is_power_of_2(sizeof(struct page))) { - pr_warn("cannot free vmemmap pages because \"struct page\" crosses page boundaries\n"); - return 0; - } - if (!buf) return -EINVAL; @@ -119,6 +113,12 @@ void __init hugetlb_vmemmap_init(struct if (!hugetlb_optimize_vmemmap_enabled()) return; + if (!is_power_of_2(sizeof(struct page))) { + pr_warn_once("cannot optimize vmemmap pages because \"struct page\" crosses page boundaries\n"); + static_branch_disable(&hugetlb_optimize_vmemmap_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 _ Patches currently in -mm which might be from songmuchun@bytedance.com are mm-hugetlb_vmemmap-disable-hugetlb_optimize_vmemmap-when-struct-page-crosses-page-boundaries.patch mm-memory_hotplug-override-memmap_on_memory-when-hugetlb_free_vmemmap=on.patch mm-hugetlb_vmemmap-use-kstrtobool-for-hugetlb_vmemmap-param-parsing.patch mm-hugetlb_vmemmap-add-hugetlb_optimize_vmemmap-sysctl.patch