Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2851611pxp; Tue, 8 Mar 2022 03:14:08 -0800 (PST) X-Google-Smtp-Source: ABdhPJyf99ZwHeEdcXv16Jj7fwCGz8TKundEtr72lKQHBi+UlAa9grJ7gLGsk6wCBU/hFbbOVWwz X-Received: by 2002:a62:7bc4:0:b0:4f6:aaa1:91f8 with SMTP id w187-20020a627bc4000000b004f6aaa191f8mr17711342pfc.48.1646738048643; Tue, 08 Mar 2022 03:14:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646738048; cv=none; d=google.com; s=arc-20160816; b=Hcd60Qs4iBAGKIgy7Un8QMRv9OCzbw5WZQPTOixDm6+8geqTCrJHPKYGZ/llEC1f9w V0UTrue/KQLGTeCjGzrVfV2ZhrSlq8pjhzrITVlfx7+RNfcDTawT2VnnqNLFGUsb0hNB U14uaU5cOvHuD/bqO67xCXsBqkxtUeaWOLPxRoE2HnZ3D6IP8Z7HT4vK7IEY5PoT8Yxc FmjHf75gRMYocKBfGXYFLlTNTuY35/8o+Tf7CQJYUVp3zzK6zQrZTNI0NxTnc8G7YaWr bgbUPC8Rl01vBaNr44Qm5h8Uj2mn6PwR1nckTeyu91rfCtm7yNQF1BdGwKhEJU+P+vVd NzVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=MFytkXFVm+nQKBfdysr1CcxHAqYCnsg45+4U4K+ObQM=; b=zvKggb3A0pAnluZWPmS8/CGz/e7VgDIF8jTlDS/s+GbnGyfmXiWqkuxhfoVHdgFdLa ZdrevzEcYhEt6EH42nm0hAoTxtznCf23RdKwJoHTAvF3nPiU6dwgnQyzDNrwoOE2vXEC aaUtSf0Y1btS871bnUCPxsltRl8+ubgWoJoV//loCmNMQtZEQqd+E0Wms/hlg+L04Ra6 T+7pnt4lYh0F3Oa0UD3A+pJ1p3qqXz83dNSnpERX183RFKcmZ27BgSddUr/n5UY25CXK LPaa2RGPVJt0/ReBFNXDmGVQBltcwa6Ar08KgdppxJdVCKeJfqeKZQRUhPr+RqUiSEAB oXjA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b="4nXPz/24"; 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 ot1-20020a17090b3b4100b001bd14e03093si2099567pjb.107.2022.03.08.03.13.49; Tue, 08 Mar 2022 03:14:08 -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="4nXPz/24"; 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 S242769AbiCGRFs (ORCPT + 99 others); Mon, 7 Mar 2022 12:05:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241464AbiCGRFp (ORCPT ); Mon, 7 Mar 2022 12:05:45 -0500 Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1BE3864BC4 for ; Mon, 7 Mar 2022 09:04:50 -0800 (PST) Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-2dc0364d2ceso171998767b3.7 for ; Mon, 07 Mar 2022 09:04:50 -0800 (PST) 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=MFytkXFVm+nQKBfdysr1CcxHAqYCnsg45+4U4K+ObQM=; b=4nXPz/240sTZkTNjrrs+YCUsZXJ69EFBHPB4zrzlis4OZy6aLv9xkGR+r5be2fVmfs PEFFMQp6c8hnOFOpwKWExugg1BcQ5/SvRKOOFxDtKUKr8y4pVFwIrFFF+rS9E0Ey6T4X t5b4BFCCWTqKOtckWBbRvAXOnqFn4jyBu2LXY6HMi0VEgnO7IaaQq1PduZfg6mjOnUGK mYXR+KWSp8EEbDu1mkeIaIpCQOzGYzMpYVmjuC2Dyzi8+jKs7p8xWcXzFSQBQ4dZzpKO TdB+ORLfdFIQKKlM1tB7rExkxI4EtpLiVN0raeK2SJKuI146TvS43W4PnTQbc3Rpc3Gw WeQQ== 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=MFytkXFVm+nQKBfdysr1CcxHAqYCnsg45+4U4K+ObQM=; b=D4+bxVjgZWsdgosmndmU7KFJ/Xmc3PANZ1pr7OmLQjgbv9OsHfpSMEzyaKJzv53C8K G6VT9NXfzARqGhDxG1LQeNNsLVT4UDqO3OXEvXiCGq4skkLJ8eNFCN5zvKYMDD37EhfI RJJoDMBJFAT5vHuHTXz20zg4lJsNkt31ctkg9yuPR4NeLGqPb+AX5fb8nrK6itcCvdhy HsbjMkh1PIsVHmDUTfWdjqqRKgAatXzapUJiRlJqAEGHVktcVljE67liX5/8EDAZ1wtQ zCN3+B2Jj0m6tJrLLvqHxHKsIiPqkunOWNXd/oS45km08dy4923qoW72nPs/3o6NQkRN FZ7A== X-Gm-Message-State: AOAM531FK8cc1uCkMAC2iADe+xMdwnx1ul22MkFLmhrkxUoAsACeunF9 GLclpI0c3MxAb/PQyyAvO5BkWudeh7XKwMYoZiNzZw== X-Received: by 2002:a0d:e609:0:b0:2d6:b8b0:8608 with SMTP id p9-20020a0de609000000b002d6b8b08608mr9223373ywe.31.1646672689245; Mon, 07 Mar 2022 09:04:49 -0800 (PST) MIME-Version: 1.0 References: <20220307130708.58771-1-songmuchun@bytedance.com> <20220307130708.58771-2-songmuchun@bytedance.com> In-Reply-To: From: Muchun Song Date: Tue, 8 Mar 2022 01:03:08 +0800 Message-ID: Subject: Re: [PATCH v3 1/4] mm: hugetlb: disable freeing vmemmap pages when struct page crosses page boundaries To: Luis Chamberlain Cc: Jonathan Corbet , Mike Kravetz , Andrew Morton , Kees Cook , Iurii Zaikin , Oscar Salvador , David Hildenbrand , Linux Doc Mailing List , LKML , Linux Memory Management List , Xiongchun duan , Muchun Song Content-Type: text/plain; charset="UTF-8" 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=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 On Tue, Mar 8, 2022 at 12:35 AM Luis Chamberlain wrote: > > On Mon, Mar 07, 2022 at 09:07:05PM +0800, Muchun Song wrote: > > 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). > > Huh what? If a panic is possible best we prevent this in kconfig > all together. I'd instead just put some work into this instead of > adding all this run time hacks. If the size of `struct page` is not power of 2, then those lines added by this patch will be optimized away by the compiler, therefore there is going to be no extra overhead to detect this. > > Can you try to add kconfig magic to detect if a PAGE_SIZE is PO2? > I agree with you that it is better if we can move this check into Kconfig. I tried this a few months ago. It is not easy to do this. How to check if a `struct page size` is PO2 in Kconfig? If you have any thoughts please let me know. Thanks.