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 0D556C433EF for ; Thu, 3 Mar 2022 02:39:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 61E008D0002; Wed, 2 Mar 2022 21:39:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A58B8D0001; Wed, 2 Mar 2022 21:39:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4487F8D0002; Wed, 2 Mar 2022 21:39:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0209.hostedemail.com [216.40.44.209]) by kanga.kvack.org (Postfix) with ESMTP id 2DA768D0001 for ; Wed, 2 Mar 2022 21:39:02 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E03D180D9BCD for ; Thu, 3 Mar 2022 02:39:01 +0000 (UTC) X-FDA: 79201517682.28.B708D5F Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) by imf29.hostedemail.com (Postfix) with ESMTP id 0B7DB120004 for ; Thu, 3 Mar 2022 02:39:00 +0000 (UTC) Received: by mail-yb1-f175.google.com with SMTP id e186so7378547ybc.7 for ; Wed, 02 Mar 2022 18:39:00 -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=XVZxRuOCFhfG5UcNmUMrWY5dCexmZUcmM57vzOUtIzc=; b=GVGoVZQOnRHwG3P1PJBo4RsNL8GTz8cSKlk7KeWh3ORutP3ONhWSiWCJv/naf7dd1p Aj2ieYCAxIGIriKvQ7QxjqwIeznojcIS6o8j0DA0n/vGhnMUDtgtUyWL9aZhyuBUMyOL iRqrBthwmJvILGWjOj5oxXyz5L9rxeW1Br5WF7pFIr1MYvl2XfiLW9LY/MqQoDi57te6 tmrtvYxRKD4DKzveOAX62nDZFsWngJajNYhwlvwJ4wqKF0WwkpPJrYM75nqyrFbWf030 yygB8L5NdBLlxDXn6BjUHB51vASX1hIK91GUP/64hrJwqTP2VbEsKMCu5JHyYRxoacls dS+w== 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=XVZxRuOCFhfG5UcNmUMrWY5dCexmZUcmM57vzOUtIzc=; b=Vh8xzBWwcZ8BKLjNgZ5Ef4rzLAiWANbrD0cvs3iR7psg6PrVGLpF+NA2lepyFP1+cZ vyiHwAI17aM9TcQPOv3uzZb8kMUJZXgJIlG2U7lH9Imv6F2Kk0oKSdKkRMHbbGPuUwPW CYERzhlis6Ny51MfRiUOcrfLkFj2jjuitebbWgcXc4xwi3dYejBGt75AiI2+6LpplbgI iaRcB4GZ8zXA7hpe8SzTO7LAZeVl0nAk1jG6s9j8PNVSMq71GhhQLLlRXCidd6OmdPau O8C5MUYaiJi203l/aRq+HgICrFGM+yIAqwkXHCRbq8evpdS8dtsw7mJzCzNS/fIxh+ol xXdA== X-Gm-Message-State: AOAM531Q+Eb4XoQ7VNTvXs1uKnEZwTSZeK98c7AsQRsQuq7nTuGNrm8f 1UJRk42QmVjZn580+kGW4VIR4PkuUJO1xvivaLCCoQ== X-Google-Smtp-Source: ABdhPJyVo566mGN4RFWjXSz/157hchstvm+m2G3uKWYOLAaPNg1L1WKOChYGCOJPt2Oz/k7cF1IPbIHim9gAA2gjasQ= X-Received: by 2002:a25:6b4a:0:b0:628:a387:6123 with SMTP id o10-20020a256b4a000000b00628a3876123mr5114625ybm.132.1646275140013; Wed, 02 Mar 2022 18:39:00 -0800 (PST) MIME-Version: 1.0 References: <20220302083758.32528-2-songmuchun@bytedance.com> In-Reply-To: From: Muchun Song Date: Thu, 3 Mar 2022 10:38:23 +0800 Message-ID: Subject: Re: [PATCH v2 1/3] 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 , Linux Doc Mailing List , LKML , Linux Memory Management List , Xiongchun duan , Muchun Song , Adam Manzanares , Davidlohr Bueso Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 0B7DB120004 X-Stat-Signature: ubeq6xwqes7ma5co4i5h84znctac6uqo Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=GVGoVZQO; spf=pass (imf29.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.219.175 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com; dmarc=pass (policy=none) header.from=bytedance.com X-Rspam-User: X-HE-Tag: 1646275140-20757 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 3, 2022 at 5:21 AM Luis Chamberlain wrote: > > On Wed, Mar 02, 2022 at 04:37:56PM +0800, Muchun Song wrote: > > If CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON is enabled and the size > > of "struct page" is not power of two, we cannot optimize vmemmap pages > > of HugeTLB pages. We should disable this feature in this case. > > The commit log does not describe what happens if this is left enabled in > that case? Is this a fix? Why would it be a fix? Was something failing? > How did you spot this issue? What are the consequences of not applying > this patch? > 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_SLAB 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 someone from configuring that combined configure. OK, this information should go to the commit log. Will update it. Thanks.