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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 950DBC433ED for ; Thu, 20 May 2021 20:01:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0273C60FE5 for ; Thu, 20 May 2021 20:01:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0273C60FE5 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 850DB8E001F; Thu, 20 May 2021 16:01:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D9928E001B; Thu, 20 May 2021 16:01:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 62C1B8E001F; Thu, 20 May 2021 16:01:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0223.hostedemail.com [216.40.44.223]) by kanga.kvack.org (Postfix) with ESMTP id 2F3F68E001B for ; Thu, 20 May 2021 16:01:15 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id C73AFDB5D for ; Thu, 20 May 2021 20:01:14 +0000 (UTC) X-FDA: 78162678468.01.401F765 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf09.hostedemail.com (Postfix) with ESMTP id E65AC6007BF8 for ; Thu, 20 May 2021 20:01:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621540873; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gf6zyBBGHXMJTYUue+5asDL+BdUUHnOyEErDg4MG/io=; b=UVoy5RJGXtjNmh7m9smzxjQKcKyIjREwml1+n3AEdVQhzcmR1dPrwL+5L3POqhXiiLuAOy krNj5RGXDiidBSyU9n3JiuLWKiKHDHKfL7rtCe2eOKW6b8ajAQOIor/X8utobbjW+gZ6cG 8SPFc1SPvpmKwhiprjnYJBj9WMYfw8w= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-569-483F6FTGOS2QLEMchXv8Fw-1; Thu, 20 May 2021 16:01:12 -0400 X-MC-Unique: 483F6FTGOS2QLEMchXv8Fw-1 Received: by mail-qv1-f70.google.com with SMTP id i14-20020a0cf10e0000b02901eeced6480dso12722761qvl.4 for ; Thu, 20 May 2021 13:01:12 -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:content-transfer-encoding :in-reply-to; bh=gf6zyBBGHXMJTYUue+5asDL+BdUUHnOyEErDg4MG/io=; b=S2AbLOcIrpIy57Q89FHuM2JZav5pxp5BB2zUjMnpUdibX0bDxRqlBB9/Kq1R9EGOAH b21RmthowJ9IDbULBOT8qWnoKy2Ij8HAH2MG6fT2Bqvcx/e39ABbXV7VaEZuTXm8GnJm O4PxNHR06r8nad9S0+XyaBkXCJj6y8xobLgBgW0cFk452n53OqkB9IAU/ZvftX4DeKlg 9JBwIadW1gkCUDICzj+qsXjzCrnTNSasBLt1M+aIWnYFjSmQcoroJC+ECsSXBK/RBDSA 02/JJQ5UVwNlKWP5EsSmgPCZcPVDAjlANMPX+f5jTRWJE4feAI//q1rIvHxQEK6E/DGe 0RzQ== X-Gm-Message-State: AOAM533JiQQEr+QDkDsaDMpO6hLKLAmBQxisqg5yXiWUt2o40Cj7avtn h+/z1yMgl1Xyhp4fKwzTO/XoZHRbFbdpv1QHyF105enwCkFo2tUxpTkz2hWXrdoC4vOYyAsO/Cx EvCnVYSZnCNY= X-Received: by 2002:ac8:570b:: with SMTP id 11mr7077226qtw.287.1621540871807; Thu, 20 May 2021 13:01:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxQXvy7GJJRJbpmFrSL46bA7N0vgvWvyK0f6kFJ9fnS7uQnwXTV7Zkqs7M5tj3WJeEIpDwbzg== X-Received: by 2002:ac8:570b:: with SMTP id 11mr7077105qtw.287.1621540870573; Thu, 20 May 2021 13:01:10 -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 s16sm1676678qtq.67.2021.05.20.13.01.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 May 2021 13:01:10 -0700 (PDT) Date: Thu, 20 May 2021 16:01:08 -0400 From: Peter Xu To: Zi Yan Cc: "Aneesh Kumar K.V" , 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-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> MIME-Version: 1.0 In-Reply-To: <4CE7132C-3800-456B-91DA-613391361B94@nvidia.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: E65AC6007BF8 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=UVoy5RJG; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf09.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: rspam03 X-Stat-Signature: dreowj8qjczkfbu1b1acc9hcqfa6kuwg X-HE-Tag: 1621540872-795303 Content-Transfer-Encoding: quoted-printable 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 03:06:30PM -0400, Zi Yan wrote: > On 20 May 2021, at 10:57, Peter Xu wrote: >=20 > > 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.. >=20 > 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.. > 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. --=20 Peter Xu 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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 28828C433ED for ; Thu, 20 May 2021 20:01:54 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6A8F0611AE for ; Thu, 20 May 2021 20:01:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6A8F0611AE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4FmLH36Kkcz3bvx for ; Fri, 21 May 2021 06:01:51 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ReH7XlIE; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ReH7XlIE; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=redhat.com (client-ip=216.205.24.124; helo=us-smtp-delivery-124.mimecast.com; envelope-from=peterx@redhat.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ReH7XlIE; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ReH7XlIE; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4FmLGT5sqgz2ym4 for ; Fri, 21 May 2021 06:01:19 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621540876; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gf6zyBBGHXMJTYUue+5asDL+BdUUHnOyEErDg4MG/io=; b=ReH7XlIE5dnZR90uAvqA/KFCSPg4gyBXw21SgTP/+1Z5OAG4zI7EvKfPODn/wVwBHl85Fw EiKKWSbJG+NoPVwx/q1Tk9LAwx7nNwodY2rH6pj1uOyXTDurNt6Jzdv+32WrjNjr/XXUVm N9tW7loMtinhxDP2yDWbVXA+Dv49Bd8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621540876; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gf6zyBBGHXMJTYUue+5asDL+BdUUHnOyEErDg4MG/io=; b=ReH7XlIE5dnZR90uAvqA/KFCSPg4gyBXw21SgTP/+1Z5OAG4zI7EvKfPODn/wVwBHl85Fw EiKKWSbJG+NoPVwx/q1Tk9LAwx7nNwodY2rH6pj1uOyXTDurNt6Jzdv+32WrjNjr/XXUVm N9tW7loMtinhxDP2yDWbVXA+Dv49Bd8= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-585-j3IKiFblOb6vBoBRV5FnAw-1; Thu, 20 May 2021 16:01:12 -0400 X-MC-Unique: j3IKiFblOb6vBoBRV5FnAw-1 Received: by mail-qt1-f199.google.com with SMTP id h2-20020a05622a1702b02901b9123889b0so13154431qtk.10 for ; Thu, 20 May 2021 13:01:12 -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:content-transfer-encoding :in-reply-to; bh=gf6zyBBGHXMJTYUue+5asDL+BdUUHnOyEErDg4MG/io=; b=lgrMv5lOnwd0mlz5OPEckb10Alpydo6YGQVUkQEerbEEFhp7IDknuJLx9YCGA7II16 s9/Ktzhb6GO+w39VMD45Ovaq0Py3uVTQp9GaqRRmOwopeUbMN0NFzr2EGiU03cpMhZOt R9HANrvhfe1X3soQgc7/985ncCZFuvxcSM05CcvmDzgRWGnyyvuWRKLNV0KwWbFW95xo IPKZbnPmJzeOyicoKVu+veHKAADxvGDZwJ3wPPmAEEdR1iYbM0UCeSSrjgW2YEz71bgg Ukr1ZwOYBKl/i0xKKDKkX8Kk/zVS9U1TIYE7ldlSgHaIk04skhdAjvpfYXoywZ8q8yDL 97TA== X-Gm-Message-State: AOAM533dyA+ag3YheLvMdoGFnpAWJGN9PuM38Vlu2yUsKkR31RWTXYCY wzP/HL0nwT5nw9lf5GVzQNbUDq1ed1ajOFY1bRfn6F2Oj17iIL1z7hP1fVIxPuwzzTc5V/It0DP 1YsDorAfbOT5En8GpOuo2bnw5ZQ== X-Received: by 2002:ac8:570b:: with SMTP id 11mr7077258qtw.287.1621540872119; Thu, 20 May 2021 13:01:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxQXvy7GJJRJbpmFrSL46bA7N0vgvWvyK0f6kFJ9fnS7uQnwXTV7Zkqs7M5tj3WJeEIpDwbzg== X-Received: by 2002:ac8:570b:: with SMTP id 11mr7077105qtw.287.1621540870573; Thu, 20 May 2021 13:01:10 -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 s16sm1676678qtq.67.2021.05.20.13.01.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 May 2021 13:01:10 -0700 (PDT) Date: Thu, 20 May 2021 16:01:08 -0400 From: Peter Xu To: Zi Yan Subject: Re: [PATCH v5 3/9] mm/mremap: Use pmd/pud_poplulate to update page table entries Message-ID: 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> MIME-Version: 1.0 In-Reply-To: <4CE7132C-3800-456B-91DA-613391361B94@nvidia.com> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=peterx@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Aneesh Kumar K.V" , kaleshsingh@google.com, npiggin@gmail.com, Nathan Chancellor , linux-mm@kvack.org, joel@joelfernandes.org, akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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, 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.. > > It seems that the mremap function for 1GB DAX THP was not added when 1GB 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.. > 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’s 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