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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 15EEDC433F5 for ; Thu, 31 Mar 2022 02:28:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 695426B0072; Wed, 30 Mar 2022 22:28:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 645086B0073; Wed, 30 Mar 2022 22:28:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E5488D0001; Wed, 30 Mar 2022 22:28:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 3BFAF6B0072 for ; Wed, 30 Mar 2022 22:28:35 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id E11D622363 for ; Thu, 31 Mar 2022 02:28:34 +0000 (UTC) X-FDA: 79303097748.06.45E5C04 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf17.hostedemail.com (Postfix) with ESMTP id 1FFE54000A for ; Thu, 31 Mar 2022 02:28:33 +0000 (UTC) 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 sin.source.kernel.org (Postfix) with ESMTPS id 8DC8DCE1F6E; Thu, 31 Mar 2022 02:28:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7637EC340F0; Thu, 31 Mar 2022 02:28:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1648693709; bh=+adBEntIzSSCVYqEhFC0POeZQwSN/e4WeFGSC39cYN0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=EcssqheLZ56lijPSSHBApcxEaeL+Lmoj5IBhJoTd7QNYuZPZuSuA/3LYmjVFeQhb0 J1syqwcskBuQ0fhmx0C2KAj1OIE8NRR1bBLk599P3q83/j0nJjxapeSy7J2GGPgTPE dJUkmRKtvEOQS/V13ifwMGLP5tMhovnjLpD7laGY= Date: Wed, 30 Mar 2022 19:28:27 -0700 From: Andrew Morton To: Muchun Song Cc: corbet@lwn.net, mike.kravetz@oracle.com, mcgrof@kernel.org, keescook@chromium.org, yzaikin@google.com, osalvador@suse.de, david@redhat.com, masahiroy@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, duanxiongchun@bytedance.com, smuchun@gmail.com Subject: Re: [PATCH v6 1/4] mm: hugetlb_vmemmap: introduce STRUCT_PAGE_SIZE_IS_POWER_OF_2 Message-Id: <20220330192827.4b95e3d7fb149ef9cc687ccb@linux-foundation.org> In-Reply-To: <20220330153745.20465-2-songmuchun@bytedance.com> References: <20220330153745.20465-1-songmuchun@bytedance.com> <20220330153745.20465-2-songmuchun@bytedance.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=EcssqheL; spf=pass (imf17.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 1FFE54000A X-Stat-Signature: gjoo66x67az6z5the4u9q3go4xpt17fg X-HE-Tag: 1648693713-170823 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 Wed, 30 Mar 2022 23:37:42 +0800 Muchun Song wrote: > If the size of "struct page" is not the power of two and this > feature is enabled, What is "this feature"? Let's spell it out? > 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 have to prevent anyone from configuring that combined > configuration. In order to avoid many checks like "is_power_of_2 > (sizeof(struct page))" through mm/hugetlb_vmemmap.c. Introduce > STRUCT_PAGE_SIZE_IS_POWER_OF_2 to detect if the size of struct > page is power of 2 and make this feature depends on this new > macro. Then we could prevent anyone do any unexpected > configuration. > > ... > > --- /dev/null > +++ b/mm/struct_page_size.c > @@ -0,0 +1,20 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Generate definitions needed by the preprocessor. > + * This code generates raw asm output which is post-processed > + * to extract and format the required data. > + */ > + > +#define __GENERATING_STRUCT_PAGE_SIZE_IS_POWER_OF_2_H > +/* Include headers that define the enum constants of interest */ > +#include > +#include > +#include > + > +int main(void) > +{ > + if (is_power_of_2(sizeof(struct page))) > + DEFINE(STRUCT_PAGE_SIZE_IS_POWER_OF_2, is_power_of_2(sizeof(struct page))); Why not DEFINE(STRUCT_PAGE_SIZE_IS_POWER_OF_2, 1); ? > + return 0; > +} > -- > 2.11.0