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=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 D17A0C433B4 for ; Thu, 20 May 2021 14:58:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5DAC461073 for ; Thu, 20 May 2021 14:58:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5DAC461073 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B8FD56B009A; Thu, 20 May 2021 10:58:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B547D6B009B; Thu, 20 May 2021 10:58:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9CDBD6B009C; Thu, 20 May 2021 10:58:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0100.hostedemail.com [216.40.44.100]) by kanga.kvack.org (Postfix) with ESMTP id 6B2756B009A for ; Thu, 20 May 2021 10:58:05 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id F38ED181AF5C7 for ; Thu, 20 May 2021 14:58:04 +0000 (UTC) X-FDA: 78161914530.06.7B508F2 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf22.hostedemail.com (Postfix) with ESMTP id E7E34C0042E1 for ; Thu, 20 May 2021 14:58:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621522684; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=IFy+kDGy5FjXwv8NN0pfzTAzqZNfkA1UTKIoWhwHib8=; b=Mu1k7wq7g3xNKVd+GlcHQVvuSftHt3VbULZv+xGbkdaVpOw6ct0zBK/px3WNIGxl0M15aS F+CKA3HbTM5vLwCkjvWhyXvhxXRxxv612TC6fx/3elxeVz+quUj3fCX2HAILta+rjkwXQ8 IU32TWgXO8juJydbvKEDRRoZwFxoOwE= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-201-HsrR2YUiNSSgepx8eU2EZQ-1; Thu, 20 May 2021 10:58:00 -0400 X-MC-Unique: HsrR2YUiNSSgepx8eU2EZQ-1 Received: by mail-qk1-f199.google.com with SMTP id s10-20020a05620a030ab02902e061a1661fso6228022qkm.12 for ; Thu, 20 May 2021 07:58:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=IFy+kDGy5FjXwv8NN0pfzTAzqZNfkA1UTKIoWhwHib8=; b=VlwhjQpbpsleQGDNtH740uwquKsObEZwLr8CJ0GllRZ9tuMAg6+rnV8PMk6Kf6efM9 rkK9+EcvZ4Y4ARXDFfBlDKuAHiQ+EyodKQRZkO9qonrEwB40btgCkYVmu/1mFLvEGW6a aKwuw3bDAXqCJjBLMasmGO82/7k31PQKFgZtA946D+3myPWz9uWaLUHojdFiqH6GpcSi JvEzcjZ6k+RYzQKmFesK6J0/J4Ob4hyONRW2IsQkOydZtS/DtUGxjaGdN5aITPyDrixQ i/F12lVx+H8kj6Pcz0OyZOUQOS00EchIxKG9cYzOXVGCd8NxcafRTG/lm3pMTDBmWGgW jEnQ== X-Gm-Message-State: AOAM531DZmgnFOl+NSJWD0DUIVibkKUrhPGuqGJZjWY42ImgWGCx1QtD KS8lDfedXi7031hZNBH9uA856H8jBVT5OcfEYr/yA/9xMjXZiUJosVQPDK8p4eAo/O2DQMEEdX0 hbaRLiXTRfs4= X-Received: by 2002:a05:620a:133b:: with SMTP id p27mr5255798qkj.354.1621522679424; Thu, 20 May 2021 07:57:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxUwFU67C8yrPnfpE5qhvyk2qLh59LFKNHs9lIWRvVbD2sY6jO7wZyKH2elnhPr9KzFI/TEfA== X-Received: by 2002:a05:620a:133b:: with SMTP id p27mr5255763qkj.354.1621522679102; Thu, 20 May 2021 07:57:59 -0700 (PDT) Received: from t490s (bras-base-toroon474qw-grc-72-184-145-4-219.dsl.bell.ca. [184.145.4.219]) by smtp.gmail.com with ESMTPSA id u186sm2253425qkd.30.2021.05.20.07.57.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 May 2021 07:57:58 -0700 (PDT) Date: Thu, 20 May 2021 10:57:56 -0400 From: Peter Xu To: "Aneesh Kumar K.V" Cc: Nathan Chancellor , linux-mm@kvack.org, akpm@linux-foundation.org, mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org, kaleshsingh@google.com, npiggin@gmail.com, joel@joelfernandes.org, Christophe Leroy Subject: Re: [PATCH v5 3/9] mm/mremap: Use pmd/pud_poplulate to update page table entries Message-ID: References: <20210422054323.150993-1-aneesh.kumar@linux.ibm.com> <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> MIME-Version: 1.0 In-Reply-To: <87o8d5le4q.fsf@linux.ibm.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Mu1k7wq7; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf22.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=peterx@redhat.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: E7E34C0042E1 X-Stat-Signature: egnqu7z6ixyn9e883ami638pdo1nredp X-HE-Tag: 1621522682-183883 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 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, however 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 calling > >>> 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 handling > > 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 not > > sure whether we handle those VMA's earlier and restrict mremap on them? > > 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 form. 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 breaking 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 better review? Agree the risk seems low. I'll leave that to you and Andrew to decide.. -- Peter Xu