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 X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 193A3C433B4 for ; Thu, 20 May 2021 20:25:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A509C6135B for ; Thu, 20 May 2021 20:25:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A509C6135B Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2E01D8D0012; Thu, 20 May 2021 16:25:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 28F758D0001; Thu, 20 May 2021 16:25:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E2188D0012; Thu, 20 May 2021 16:25:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0058.hostedemail.com [216.40.44.58]) by kanga.kvack.org (Postfix) with ESMTP id CD51E8D0001 for ; Thu, 20 May 2021 16:25:20 -0400 (EDT) Received: from smtpin35.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 61B56249A for ; Thu, 20 May 2021 20:25:20 +0000 (UTC) X-FDA: 78162739200.35.0061C7E Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by imf22.hostedemail.com (Postfix) with ESMTP id 4E426C0042C4 for ; Thu, 20 May 2021 20:25:18 +0000 (UTC) Received: by mail-pj1-f52.google.com with SMTP id g6-20020a17090adac6b029015d1a9a6f1aso5865046pjx.1 for ; Thu, 20 May 2021 13:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XzhGwED4BuY8EZ9RKSvkQjl/BPgxFgPze0agT2jSi8I=; b=BUVIgtmEWYeN2zpTngphN5XPLJ1ipBFQv511iAX9jiVrgQzU9MZnS8u1RWtoQHAoT5 1WTh7EUT9Wy39ANzCFuAkGgl7mQizm7nL7HLT157tU5ROpYuEtIOuPX2hCRxmGculO29 F8IeMxtRlMF7OovrJRT/Nv3GckBUy+d0JIS+CpqrjqHnom+7oCrGXK9/ub0GlI2EOetU zBopcW4uN28UkXRE6r1sipWUy7iwLZZDH9ZrjKehY+h3IKUDR8vWqzVzK4pJQhRXMbRe K6OXDninjIFFECdZ9gt849NneQJEKMvZsWaNYBSVyBIiJRN9dzkGXdhK3LnkUi6aO1qT SjYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=XzhGwED4BuY8EZ9RKSvkQjl/BPgxFgPze0agT2jSi8I=; b=YAIEcA+V652TiD7Js0zoae2D4h4In+Pd8HeUxlwMl+q0yKA40Dxmp5Qm8G7hvAvHrQ seiZPdtpwWpXnlH+RKUhBDxXQFYCIL5Y6lLe/il4DQppSNnvthmY18PWIZMQoPMIAgp9 9pUM+in2Fsf3E9PWpTZgUhqkGRDMLpc3s+8zQnbaTAuFdvWTumZ6HLn9MCUlwEkDlUEJ sWaeEm7xM7fkwLAkrblct/REPCcaNBEDkHP3KSlluNUKDJlHLEYUB0WufLqUyzQ3DYuK dkh5r552s/mTPT6iOF07ci0+gZorpQHNF6/a7P7xE8SOmdVoASKes5rVp7Gan7iNQs1e P6+A== X-Gm-Message-State: AOAM532rLc1Niy2hd3xbUl2csB1i4xydOQSJAb9R+6z8c5yzn4+YZ2L6 iRpFIZ75seu/UBAYAA9kFOK0QFMm3Htg9y5f4AXg2A== X-Google-Smtp-Source: ABdhPJxPBQFMSTXN6pxg+uvafPCvn2Xzp3tjqf6LlBqJEJmNMsB25yGvi8xYdijYwUFS03reeDVbiKGFEu0UqylaRl4= X-Received: by 2002:a17:90a:6644:: with SMTP id f4mr6760932pjm.154.1621542318759; Thu, 20 May 2021 13:25:18 -0700 (PDT) MIME-Version: 1.0 References: <20210422054323.150993-4-aneesh.kumar@linux.ibm.com> <87mtsrqqk0.fsf@linux.ibm.com> <6e0dbb76-2b33-53f1-246e-30cec2b871e2@linux.ibm.com> <87o8d5le4q.fsf@linux.ibm.com> <4CE7132C-3800-456B-91DA-613391361B94@nvidia.com> In-Reply-To: From: Kalesh Singh Date: Thu, 20 May 2021 16:25:07 -0400 Message-ID: Subject: Re: [PATCH v5 3/9] mm/mremap: Use pmd/pud_poplulate to update page table entries To: Peter Xu Cc: Zi Yan , "Aneesh Kumar K.V" , Nathan Chancellor , "open list:MEMORY MANAGEMENT" , Andrew Morton , mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org, npiggin@gmail.com, joel@joelfernandes.org, Christophe Leroy Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4E426C0042C4 Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=BUVIgtmE; spf=pass (imf22.hostedemail.com: domain of kaleshsingh@google.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=kaleshsingh@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam04 X-Stat-Signature: r4gdtms9jncxcg8kuu1hjw1fzsdgi7te X-HE-Tag: 1621542318-546857 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, May 20, 2021 at 4:01 PM Peter Xu wrote: > > On Thu, May 20, 2021 at 03:06:30PM -0400, Zi Yan wrote: > > On 20 May 2021, at 10:57, Peter Xu wrote: > > > > > On Thu, May 20, 2021 at 07:07:57PM +0530, Aneesh Kumar K.V wrote: > > >> "Aneesh Kumar K.V" writes: > > >> > > >>> On 5/20/21 6:16 PM, Peter Xu wrote: > > >>>> On Thu, May 20, 2021 at 01:56:54PM +0530, Aneesh Kumar K.V wrote: > > >>>>>> This seems to work at least for my userfaultfd test on shmem, ho= wever I don't > > >>>>>> fully understand the commit message [1] on: How do we guarantee = we're not > > >>>>>> moving a thp pte? > > >>>>>> > > >>>>> > > >>>>> move_page_tables() checks for pmd_trans_huge() and ends up callin= g > > >>>>> move_huge_pmd if it is a THP entry. > > >>>> > > >>>> Sorry to be unclear: what if a huge pud thp? > > >>>> > > >>> > > >>> I am still checking. Looking at the code before commit > > >>> c49dd340180260c6239e453263a9a244da9a7c85, I don't see kernel handli= ng > > >>> huge pud thp. I haven't studied huge pud thp enough to understand > > >>> whether c49dd340180260c6239e453263a9a244da9a7c85 intent to add that > > >>> support. > > >>> > > >>> We can do a move_huge_pud() like we do for huge pmd thp. But I am n= ot > > >>> sure whether we handle those VMA's earlier and restrict mremap on t= hem? > > >> > > >> something like this? (not even compile tested). I am still not sure > > >> whether this is really needed or we handle DAX VMA's in some other f= orm. > > > > > > Yeah maybe (you may want to at least drop that extra "case HPAGE_PUD"= ). > > > > > > It's just that if with CONFIG_HAVE_MOVE_PUD (x86 and arm64 enables it= by > > > default so far) it does seem to work even with huge pud, while after = this patch > > > it seems to be not working anymore, even with your follow up fix. > > > > > > Indeed I saw CONFIG_HAVE_MOVE_PUD is introduced a few months ago so b= reaking > > > someone seems to be unlikely, perhaps no real user yet to mremap() a = huge pud > > > for dax or whatever backend? > > > > > > Ideally maybe rework this patch (or series?) and repost it for a bett= er review? > > > Agree the risk seems low. I'll leave that to you and Andrew to decid= e.. > > > > It seems that the mremap function for 1GB DAX THP was not added when 1G= B DAX THP > > was implemented[1]. > > Yes, but trickily as I mentioned it seems Android's CONFIG_HAVE_MOVE_PUD = has > done this right (with no intention I guess) with the set_pud_at() before = this > patch is merged, so we might have a short period that this might start to= work.. > It may have coincidentally handled the huge PUD case, but I hadn't considered huge PUDs when implementing the HAVE_MOVE_PUD patchset. Or as Zi suggested, huge PUD mremap may be unused atm, I haven't seen any related breakages since enabling HAVE_MOVE_PUD for x86 and arm64 > > I guess no one is using mremap on 1GB DAX THP. Maybe we want > > to at least add a warning or VM_BUG_ON to catch this or use Aneesh=E2= =80=99s move_huge_pud() > > to handle the situation properly? > > Agreed, if we decide to go with the patches, some warning (or even VM_BUG= _ON, > which iiuc should be very not-suggested in most cases) looks better than > pgtable corruption reports. > > -- > Peter Xu >