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 6163CC433EF for ; Thu, 31 Mar 2022 02:53:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CBAE98D0001; Wed, 30 Mar 2022 22:53:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C69D56B0073; Wed, 30 Mar 2022 22:53:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B0A408D0001; Wed, 30 Mar 2022 22:53:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 9EA0C6B0072 for ; Wed, 30 Mar 2022 22:53:35 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 680D420A50 for ; Thu, 31 Mar 2022 02:53:35 +0000 (UTC) X-FDA: 79303160790.02.9434E49 Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) by imf24.hostedemail.com (Postfix) with ESMTP id D124F180006 for ; Thu, 31 Mar 2022 02:53:34 +0000 (UTC) Received: by mail-yb1-f176.google.com with SMTP id j2so40125256ybu.0 for ; Wed, 30 Mar 2022 19:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LDGcIKDDCWfntxIrDwg9NeEeCU9Lt3ZtVZJtgLcXbjo=; b=ehvnGf0k3aAoq9MC2JYKyRY0i4dKaTVRiQuSZTvJKKIQkMCypskYgzN4Xm/JZ52RC/ vK4R4fZ/MtrdkHepjo7BcnI12BnCd+kS2eiqIJB2uoKfcoKGfxcSryGLZzFQXRB/SSqA WxQDRxBwkq47q9kYArRurS3/a/bs9pEhxJ4HWxa/v1mvrJrPsrZgUm21pX5NOE+NCmYP NTDa4hYvbaVQvfUj7MoHdxT+X99VAM/tHihgKAzlBkVVtDaqc9MOOPAHACpZtT83gCk9 cRehK8HZzQ+ywONbDwHF9mFr7g1MEi3Q4cFY7IJOnk+VwX8lXE1NdbVVHaR6WIZUAUdT nC0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LDGcIKDDCWfntxIrDwg9NeEeCU9Lt3ZtVZJtgLcXbjo=; b=yNGg/u3PYibIWiFPN17oDbf3K/Y6tEh0DaQSVY1bIfG/6RV9QUieiKCr6n6i64yGPO /0Ct8lXGE7O9doo/HnJeDoToJRkyi6yhDvFhrWNfNjGCLAg+HZRzuQcwuivHtkdJh+fg XBkM7PSidbFnHJYwUYgwa4hZcjwHGva+k/JSXEgITZIGbwLsoBeOVxDngFVxjczTU7oD lp2Mw1Cs+3Thi8IF9tzQrD56+dUGvLNF3dgGARqDv5TPN6Bx41/8sOKfFSJv26VSs7FW YBuHpw1p0t9OjDkmZ3DbY/TwVtOQ/Q3/AMnuPOuI4MvvJQGL+tIQbuIBpDmV/Wd+dnea IpTg== X-Gm-Message-State: AOAM533mejK0ZLgDEzC3auH53ZAHnimEpjC2LAcFz/o3LiH2pR0XWGSl VR7NncUQXCUbHm/IL/X/Maf96rA94AIkTyUOIis0UA== X-Google-Smtp-Source: ABdhPJxAoUYq0gy2PYb5dAIdtttQkFTZaQDjRFIKDP9yxDhDCV22s3LsslKjxvT4uh0wdtnGs1uY4ySHCJU1/VDmZh8= X-Received: by 2002:a25:e70e:0:b0:634:1a47:4ff2 with SMTP id e14-20020a25e70e000000b006341a474ff2mr2484276ybh.89.1648695213764; Wed, 30 Mar 2022 19:53:33 -0700 (PDT) MIME-Version: 1.0 References: <20220330153745.20465-1-songmuchun@bytedance.com> <20220330153745.20465-2-songmuchun@bytedance.com> <20220330192827.4b95e3d7fb149ef9cc687ccb@linux-foundation.org> In-Reply-To: <20220330192827.4b95e3d7fb149ef9cc687ccb@linux-foundation.org> From: Muchun Song Date: Thu, 31 Mar 2022 10:52:58 +0800 Message-ID: Subject: Re: [PATCH v6 1/4] mm: hugetlb_vmemmap: introduce STRUCT_PAGE_SIZE_IS_POWER_OF_2 To: Andrew Morton Cc: Jonathan Corbet , Mike Kravetz , Luis Chamberlain , Kees Cook , Iurii Zaikin , Oscar Salvador , David Hildenbrand , Masahiro Yamada , Linux Doc Mailing List , LKML , Linux Memory Management List , Xiongchun duan , Muchun Song Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: D124F180006 X-Stat-Signature: ixs3dg6t981n1ux9679ags597i3z1yqf X-Rspam-User: Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=ehvnGf0k; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf24.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com X-HE-Tag: 1648695214-190231 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 Thu, Mar 31, 2022 at 10:28 AM Andrew Morton wrote: > > 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? Will do. > > > 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); > Yep, this is more simple. But the 2nd parameter of DEFINE() will go into the comments. I want to make it more clear when someone reads the code of this macro. The two different sentences will generate the following two different comments. Which one do you think is better? #define STRUCT_PAGE_SIZE_IS_POWER_OF_2 1 /* is_power_of_2(sizeof(struct page)) */ #define STRUCT_PAGE_SIZE_IS_POWER_OF_2 1 /* 1 */ Thanks.