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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id B9689C3DA49 for ; Thu, 25 Jul 2024 22:42:15 +0000 (UTC) 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=TYWnhLea; 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=TYWnhLea; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4WVQqp074Bz3cgM for ; Fri, 26 Jul 2024 08:42:14 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=redhat.com 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=TYWnhLea; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=TYWnhLea; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=redhat.com (client-ip=170.10.129.124; helo=us-smtp-delivery-124.mimecast.com; envelope-from=peterx@redhat.com; receiver=lists.ozlabs.org) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4WVQq12437z3cJl for ; Fri, 26 Jul 2024 08:41:29 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1721947284; 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=u5IjTDKou7RsegoJDQrUdTSsaR0wePSmCha5JTdz6Yk=; b=TYWnhLeauTdnLMp6mW/L/tNLNzroBP6rdUDxa2uRYEUSb/uM6whUzLjgZhgRmGxnemtMJ3 eV5LdY6YtOkghZCgQ0pS9vlavib4IodOraXJPNHAmCwoqf9ZQtUExAJWYrox1IO3U8uXYv ABJA2HgjVDGh8zJEKKFlNKra+zI2PTY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1721947284; 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=u5IjTDKou7RsegoJDQrUdTSsaR0wePSmCha5JTdz6Yk=; b=TYWnhLeauTdnLMp6mW/L/tNLNzroBP6rdUDxa2uRYEUSb/uM6whUzLjgZhgRmGxnemtMJ3 eV5LdY6YtOkghZCgQ0pS9vlavib4IodOraXJPNHAmCwoqf9ZQtUExAJWYrox1IO3U8uXYv ABJA2HgjVDGh8zJEKKFlNKra+zI2PTY= Received: from mail-ot1-f70.google.com (mail-ot1-f70.google.com [209.85.210.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-423-S4UVYFc8P8KjQ0_yMkz4Pg-1; Thu, 25 Jul 2024 18:41:22 -0400 X-MC-Unique: S4UVYFc8P8KjQ0_yMkz4Pg-1 Received: by mail-ot1-f70.google.com with SMTP id 46e09a7af769-7093752a9f5so72157a34.1 for ; Thu, 25 Jul 2024 15:41:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721947282; x=1722552082; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=u5IjTDKou7RsegoJDQrUdTSsaR0wePSmCha5JTdz6Yk=; b=plCTzSs6hnaBrXnDwe1uuIPLCT9UaERETEweK/G+FLoKClf2Sh39yKwa4DlMn3mPE3 QmNwW4lKPafrG2qCCgea2ekuLmTBwbzVa+F8qhx8gDlDRN4MKQPREqR7mPiv/9S2p6dj wsZ5d/bMb77pDqoBK8wrkdr8VFWj0j0H5HrSrHMzMIA2i9zq8H9KQkk7itk5IqaGnJO9 6WuSUgol5s8taHVN7Xeqp3HFg2XvZLJR9ywMswFa6sn2IbIk7Lri2wEOSMKVl81RYxgq HTwO3Q4E8JTWxTii1qjRMFOuo66w8f6NE2q5hnHluqeMGvFg7HLgMQxF5LeOsEww7Kbj f9pA== X-Forwarded-Encrypted: i=1; AJvYcCXQgw2SdZew6rpjP/+y0WffU8vN5VRyqziYo9+2AfTJsBakhhyQlWotgFSa3j910WkAiQbmo4xXudY1+A0=@lists.ozlabs.org X-Gm-Message-State: AOJu0YxvWghJqTOmD0W8GW7XI/F+3YjEeEQkMnIPo3Pu6uIs9ZluUFbx HNOVaiIhTUZcWgSA04dZw4jSL3ooFMgMPcJFRIYt09vKQJnc+SgMZveWMUvTd+wvAXGAFJbJUW3 zEAJ+AH2hk+wmp1XPjGrsFJbEKLHJ+ZhRlPA8gvliVZUBC7ZWUnKDHXRXH0LuSJc= X-Received: by 2002:a05:6830:1651:b0:703:5c54:ddac with SMTP id 46e09a7af769-7092fa57dc7mr2750324a34.2.1721947281940; Thu, 25 Jul 2024 15:41:21 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGxIL6o6NZPBdYvHx1uIaunP84Pm7SW2ixxgCYcEwJ2VgyEqi0/RBTDXtRm2M6ZYXomWlm6fw== X-Received: by 2002:a05:6830:1651:b0:703:5c54:ddac with SMTP id 46e09a7af769-7092fa57dc7mr2750314a34.2.1721947281608; Thu, 25 Jul 2024 15:41:21 -0700 (PDT) Received: from x1n (pool-99-254-121-117.cpe.net.cable.rogers.com. [99.254.121.117]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7a1d739810bsm123991185a.16.2024.07.25.15.41.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Jul 2024 15:41:21 -0700 (PDT) Date: Thu, 25 Jul 2024 18:41:17 -0400 From: Peter Xu To: James Houghton Subject: Re: [PATCH v3 8/8] mm/mprotect: fix dax pud handlings Message-ID: References: <20240715192142.3241557-1-peterx@redhat.com> <20240715192142.3241557-9-peterx@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline 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: Dave Hansen , linux-mm@kvack.org, Christophe Leroy , Dan Williams , Dave Jiang , "Aneesh Kumar K . V" , x86@kernel.org, Hugh Dickins , Matthew Wilcox , Ingo Molnar , Huang Ying , Rik van Riel , Nicholas Piggin , Borislav Petkov , "Kirill A . Shutemov" , Thomas Gleixner , Vlastimil Babka , Oscar Salvador , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Andrew Morton , Rick P Edgecombe , Mel Gorman Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Thu, Jul 25, 2024 at 11:29:49AM -0700, James Houghton wrote: > > - pages += change_pmd_range(tlb, vma, pud, addr, next, newprot, > > + > > + if (pud_leaf(pud)) { > > + if ((next - addr != PUD_SIZE) || > > + pgtable_split_needed(vma, cp_flags)) { > > + __split_huge_pud(vma, pudp, addr); > > + goto again; > > IIUC, most of the time, we're just going to end up clearing the PUD in > this case. __split_huge_pud() will just clear it, then we goto again > and `continue` to the next pudp. Is that ok? > > (I think it's ok as long as: you never map an anonymous page with a > PUD, I think this is true. > and that uffd-wp is not usable with non-hugetlb PUD mappings of > user memory (which I think is only DAX?). Uffd-wp has the async mode that can even work with dax puds.. even though I don't think anyone should be using it. Just like I'm more sure that nobody is using mprotect() too with dax pud, and it further justifies why nobody cared this much.. What uffd-wp would do in this case is it'll make pgtable_split_needed() returns true on this PUD, the PUD got wiped out, goto again, then change_prepare() will populate this pud with a pgtable page. Then it goes downwards, install PMD pgtable, then probably start installing pte markers ultimately if it's a wr-protect operation. > So it seems ok today...?) Yes I think it's ok so far, unless you think it's not. :) > > Also, does the comment in pgtable_split_needed() need updating? /* * Return true if we want to split THPs into PTE mappings in change * protection procedure, false otherwise. */ It looks to me it's ok for now to me? THP can represents PUD in dax, and we indeed want to break THPs (no matter PUD/PMD) finally into PTE mappings. > > Somewhat related question: change_huge_pmd() is very careful not to > clear the PMD before writing the new value. Yet change_pmd_range(), > when it calls into __split_huge_pmd(), will totally clear the PMD and > then populate the PTEs underneath (in some cases at least), seemingly > reintroducing the MADV_DONTNEED concern. But your PUD version, because > it never re-populates the PUD (or PMDs/PTEs underneath) does not have > this issue. WDYT? Could you elaborate more on the DONTNEED issue you're mentioning here? > > Thanks for this series! Thanks for reviewing it, James. -- 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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2C564C3DA49 for ; Thu, 25 Jul 2024 22:41:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E2016B0093; Thu, 25 Jul 2024 18:41:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8929E6B0095; Thu, 25 Jul 2024 18:41:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 731FB6B0096; Thu, 25 Jul 2024 18:41:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 51E966B0093 for ; Thu, 25 Jul 2024 18:41:27 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E912E1A13FE for ; Thu, 25 Jul 2024 22:41:26 +0000 (UTC) X-FDA: 82379747772.12.3FD7705 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf25.hostedemail.com (Postfix) with ESMTP id DBC69A000D for ; Thu, 25 Jul 2024 22:41:24 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=TYWnhLea; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf25.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721947229; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=u5IjTDKou7RsegoJDQrUdTSsaR0wePSmCha5JTdz6Yk=; b=I9Hb4SXMR5AsNRcwR5HSNnw0AX1zY/YiJkRvnA7g5auXie0d4/fiODkd2BuOVgHC6AFg37 N26RWCioVZuCCeQaZCO8/qSlVzmCo+sCAh6r22S2dbGtnnIicN1buTFL5MuWcwQMeiPXvt Dqf4i/Il4f1DnUFXDWQBBFqR5MGKZik= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721947229; a=rsa-sha256; cv=none; b=5t42qLkd7GwYB80OBJVtaLwuHLAPz2I0h9h6NhTvbeiyWRfMG71DJlK/b1cDTzkq2X7niB FQocV3wg6/Rz2343pJHn4yr7u8pC5l0v0KAh18bvdEBvX1NfGkDP6a9WVNpuM9yLB0T/wN N/qwiX4PJh27WpedhAboLtItr1lbn34= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=TYWnhLea; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf25.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1721947284; 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=u5IjTDKou7RsegoJDQrUdTSsaR0wePSmCha5JTdz6Yk=; b=TYWnhLeauTdnLMp6mW/L/tNLNzroBP6rdUDxa2uRYEUSb/uM6whUzLjgZhgRmGxnemtMJ3 eV5LdY6YtOkghZCgQ0pS9vlavib4IodOraXJPNHAmCwoqf9ZQtUExAJWYrox1IO3U8uXYv ABJA2HgjVDGh8zJEKKFlNKra+zI2PTY= Received: from mail-ot1-f71.google.com (mail-ot1-f71.google.com [209.85.210.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-423-pGHAXA62ObePN2c21BS76A-1; Thu, 25 Jul 2024 18:41:22 -0400 X-MC-Unique: pGHAXA62ObePN2c21BS76A-1 Received: by mail-ot1-f71.google.com with SMTP id 46e09a7af769-7093752a9f5so72158a34.1 for ; Thu, 25 Jul 2024 15:41:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721947282; x=1722552082; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=u5IjTDKou7RsegoJDQrUdTSsaR0wePSmCha5JTdz6Yk=; b=p+qKTelkFZwb3c1v6O0OuLj9A5n+T+foZNvoT/n3dlV9/h7QE16QOCYalFztT3lW+n OBnZcoeaan24VkdApk8Se3KeNipulVyaulMI5YJ6qaCGP1v28XcGEtSOSDrg3jY7/IXh aXNPWUmJ07idSmKJSHBcH1+2ECA6NerAV78+/Y0m2b2vj2cUsUtSqb8zwwcormWueGgU VzKcBBh2Nwu7yR91NQyI8WR9EMwFEGS5jDnxp+1rFmMJdimx+A4DC+03orkwKWnoqJhD wGDWBlbMucqQtQKWrt175W/xdBt9Sgq6MrWxz5/3TPW0jj0xQsyslHP1EHWzg+bnN5xk CRtg== X-Gm-Message-State: AOJu0YweiBM+z37cMMLIQvkkJMyaLgEjtWBhcr9Ljvoa4YVKiWRsRCpJ 0EiVEolsZivMpx4V0xypqymKJrd9+vEY8XXUfRKN+CaxZQIXZdCkHFlS3HU8qYvSzvv8PrWbFKD CCPKzhUyQfP0ZsZpqlZ8WFXwVNf/Sfnw4dM0K4QvMY7vjdQNs X-Received: by 2002:a05:6830:1651:b0:703:5c54:ddac with SMTP id 46e09a7af769-7092fa57dc7mr2750332a34.2.1721947281942; Thu, 25 Jul 2024 15:41:21 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGxIL6o6NZPBdYvHx1uIaunP84Pm7SW2ixxgCYcEwJ2VgyEqi0/RBTDXtRm2M6ZYXomWlm6fw== X-Received: by 2002:a05:6830:1651:b0:703:5c54:ddac with SMTP id 46e09a7af769-7092fa57dc7mr2750314a34.2.1721947281608; Thu, 25 Jul 2024 15:41:21 -0700 (PDT) Received: from x1n (pool-99-254-121-117.cpe.net.cable.rogers.com. [99.254.121.117]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7a1d739810bsm123991185a.16.2024.07.25.15.41.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Jul 2024 15:41:21 -0700 (PDT) Date: Thu, 25 Jul 2024 18:41:17 -0400 From: Peter Xu To: James Houghton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dave Jiang , Rik van Riel , Dave Hansen , Michael Ellerman , linuxppc-dev@lists.ozlabs.org, Matthew Wilcox , Rick P Edgecombe , Oscar Salvador , Mel Gorman , Andrew Morton , Borislav Petkov , Christophe Leroy , Huang Ying , "Kirill A . Shutemov" , "Aneesh Kumar K . V" , Dan Williams , Thomas Gleixner , Hugh Dickins , x86@kernel.org, Nicholas Piggin , Vlastimil Babka , Ingo Molnar Subject: Re: [PATCH v3 8/8] mm/mprotect: fix dax pud handlings Message-ID: References: <20240715192142.3241557-1-peterx@redhat.com> <20240715192142.3241557-9-peterx@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: DBC69A000D X-Stat-Signature: ms31meghg4bjp4hmpsm5xx4ag9yspmp5 X-Rspam-User: X-HE-Tag: 1721947284-254909 X-HE-Meta: U2FsdGVkX18wxL8h22u2hOo3AnEmXSIJb1oO8zn4dU3IEL/NLYeqWtbcJJ46eWzUh3kM+ECkID3WmW3JWy0EF+R19Ontq3hqdGQjOqsguFR9aBmuJVep4iUYIKBtLnxTKBDX04zykEchjR5/0baFlX0MZ/AVOYknErsek1Prk5VjNToUJKf5T+Fdxet3XvojGQg2y5KqwDq+RGtwEKseLM5ticuyjfpx6JZ6aAF3mrNEATT8GWix2dFszeHoap7//byJDrZBOZLkBBQm9fwlsaACHWmZAd4wdyNshiPdYBTzfOr6/DPePsatLJ2iennpcwDTMZajskmNrSsgilwu8RdFh8l7y6DtvkyYvoSp/ydqIk+c1soLXli5dm3/BDbSs9euIZtSqgeLNbQelikqDCVFJeQsna2tm3EXLrQHrlvjFVftfP3b136fQq2+8GFtgpINVIVa2u8QGXQ2PUsZ4CTTV5zGh2xNy69JgovK4EG4vtihgVzkNyjs6Kz0lmf0LGsJ449b10FTHAjm43aXrqFjxAd9vFzDOY5vyizgtEnRmJk5pYnw78q2zUUcMamMzUdCMZQVo5bQ3hPUG1XzSMxwC5Ra4/z0pjS7CTO/jHFNN/JDSaLFNNLW1rBgGPNbEVfFcKsN4sIORos33Zzd09VHR7tjwpAwouQwqwgAA4JldSvTrMt5DCzX6xndZOU+8QDWP6/Zkx8wtuz+G02V2RJmMaikLHjv9kyCLFgmXzzYidHI+UuAn99lrJvy9B+mdtqd2ZMt+pAW3fi5qhTL6x9bUemv69WbYigMiCzsciPggDrSD4ey/muzWoCao6E/hlqHS7Yi2+rlUFwKo22Zcnb2ZjrSaLeYHxrcGdArMxP/htViP9f+usnILqIQX+ttdj4bah/OhDX8gvtOWyCMYriyHzioTzOASkVr+GzCRAg5KBl4wYzyz1tISiuTGa9mD3JrQrpSIXffg3MtCa1 Th0rkcHB fOTHrUniiiTxouS98j1jbR8G6gQ0wvVegXAjOYH5Zd9BtJ7SeS646KVz20CAVn4yP6T8b2haZXqbQP9ZMzfw7ru65McqUL5b6pMl2NoZ5QWTMeCvsOLMHvkoaikmURTP2KniVu+yQpqb1dec1HtGT9osAcpmph0jL8k1fG9EfR/6MMAcbujeJ3kO5noBvbyJZaKjlpzj3+Qlgkek1kHg4pwK5ISvkjdeRipae86farq+NzzChRm55owRym5WUOdN3RQGQu2YTjee0BVkH/kIoa3iv/MxAtOvlCEfKRsIY4qTqcYzSUGJLJuu1jcInMIW4Bk1BkRq66plIDW20tlNH9hVLObuCFVpxf24pG9ptRx6gQvzKnGavw//RbsyF26RSOIi5rwxUeu9EJEpj+V3dZ/ewQcr61wgAAUxrkUBd/BtTBjYJhxc4wBvokQ== 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: List-Subscribe: List-Unsubscribe: On Thu, Jul 25, 2024 at 11:29:49AM -0700, James Houghton wrote: > > - pages += change_pmd_range(tlb, vma, pud, addr, next, newprot, > > + > > + if (pud_leaf(pud)) { > > + if ((next - addr != PUD_SIZE) || > > + pgtable_split_needed(vma, cp_flags)) { > > + __split_huge_pud(vma, pudp, addr); > > + goto again; > > IIUC, most of the time, we're just going to end up clearing the PUD in > this case. __split_huge_pud() will just clear it, then we goto again > and `continue` to the next pudp. Is that ok? > > (I think it's ok as long as: you never map an anonymous page with a > PUD, I think this is true. > and that uffd-wp is not usable with non-hugetlb PUD mappings of > user memory (which I think is only DAX?). Uffd-wp has the async mode that can even work with dax puds.. even though I don't think anyone should be using it. Just like I'm more sure that nobody is using mprotect() too with dax pud, and it further justifies why nobody cared this much.. What uffd-wp would do in this case is it'll make pgtable_split_needed() returns true on this PUD, the PUD got wiped out, goto again, then change_prepare() will populate this pud with a pgtable page. Then it goes downwards, install PMD pgtable, then probably start installing pte markers ultimately if it's a wr-protect operation. > So it seems ok today...?) Yes I think it's ok so far, unless you think it's not. :) > > Also, does the comment in pgtable_split_needed() need updating? /* * Return true if we want to split THPs into PTE mappings in change * protection procedure, false otherwise. */ It looks to me it's ok for now to me? THP can represents PUD in dax, and we indeed want to break THPs (no matter PUD/PMD) finally into PTE mappings. > > Somewhat related question: change_huge_pmd() is very careful not to > clear the PMD before writing the new value. Yet change_pmd_range(), > when it calls into __split_huge_pmd(), will totally clear the PMD and > then populate the PTEs underneath (in some cases at least), seemingly > reintroducing the MADV_DONTNEED concern. But your PUD version, because > it never re-populates the PUD (or PMDs/PTEs underneath) does not have > this issue. WDYT? Could you elaborate more on the DONTNEED issue you're mentioning here? > > Thanks for this series! Thanks for reviewing it, James. -- Peter Xu