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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9EAF3EB64DA for ; Thu, 15 Jun 2023 14:58:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239846AbjFOO62 (ORCPT ); Thu, 15 Jun 2023 10:58:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40144 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345151AbjFOO6R (ORCPT ); Thu, 15 Jun 2023 10:58:17 -0400 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AB45E2D50 for ; Thu, 15 Jun 2023 07:58:15 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-51400fa347dso10694a12.0 for ; Thu, 15 Jun 2023 07:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1686841094; x=1689433094; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fFEMMsnaVMMTN+MNrLJhPSERf9Iz01XRTKYXqWbDbKw=; b=q94/N+S0ANP0qfo3iED0X3GUvb12lTH4j3QOzDNGtZE/B+3GOiOiLpIeZ54MPTMd4f lwLiM6RyD3FqWgDXOqXvCeLoOQaVfjgXUPDwGWebKkwKb+YuJPikfarnPzMI4LtrmcBp y847xtkBebIRxzn8FikqQYnBHrlWutgujnpGaE4VZgsOJWgOTV689TI6qVQ1qvBNqLgG 4jfDLEuUCHIPmbOpUc2Dhetj7azg6cB+6vZsd/ovfnkOyGmWoR6xsqduCMHyySUhvtDp zjwhO1KKBFysS18i7RB4CCsDxAjV2kRP6wynwyVEZExck+itLa+oePesLzVuvAxDNsOi g2Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686841094; x=1689433094; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fFEMMsnaVMMTN+MNrLJhPSERf9Iz01XRTKYXqWbDbKw=; b=LpCjNv0mvv+ruA+V+cpG+Lf7QDqtRZrlbz81ffHVXs6fgrSMuPl2o9WocylSaqVsC8 JvXt1lQ35eGk3UXjfAhLIN7dwknIX7NEtjd0phhHaOiqgqsxT9VmfhxS8KIF7MzWNkpc Xl8q+hxf7LFkcqlcHgDQzEbyKcamgOe10Rx6QQKSi69jSXT09z1NSs+QdaP6aj0k9R7F E1pgMxV8Xxo/l+xL/0qzGqchrLXN2A4UAFCtWq2e75pqTsBm1onNNxpSbuBK+N4jKj9S Rn5up5ag+Qt/ZTxLviY+0JoI8VIVJngp4oAI40vsNqyAbwQRiIwVJop/4gyvYNU3+S3R 2Wlw== X-Gm-Message-State: AC+VfDw8km1v/McEOZJWqr+6Oj3BetQq8vNFOofI1LXxAHPPGAaib/aM XZpDpU709xuNiXAETiUPkmaU37lt1eZHRiTo9z9/oQ== X-Google-Smtp-Source: ACHHUZ4WXsDVRmMbD5nLQbERxBnWATUeJeVD98IO3VjjPOWmZCV24bKxbxwmLV9CtMkgeyPYIeCORQhTu7shXQ2gF+w= X-Received: by 2002:a50:9faf:0:b0:514:92e4:ab9f with SMTP id c44-20020a509faf000000b0051492e4ab9fmr69956edf.7.1686841093992; Thu, 15 Jun 2023 07:58:13 -0700 (PDT) MIME-Version: 1.0 References: <20230613102905.2808371-1-usama.anjum@collabora.com> <20230613102905.2808371-3-usama.anjum@collabora.com> <0db01d90-09d6-08a4-bbb8-70670d3baa94@collabora.com> <34203acf-7270-7ade-a60e-ae0f729dcf70@collabora.com> <96b7cc00-d213-ad7d-1b48-b27f75b04d22@collabora.com> In-Reply-To: From: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= Date: Thu, 15 Jun 2023 16:58:02 +0200 Message-ID: Subject: Re: [PATCH v18 2/5] fs/proc/task_mmu: Implement IOCTL to get and optionally clear info about PTEs To: Muhammad Usama Anjum Cc: Peter Xu , David Hildenbrand , Andrew Morton , Andrei Vagin , Danylo Mocherniuk , Paul Gofman , Cyrill Gorcunov , Mike Rapoport , Nadav Amit , Alexander Viro , Shuah Khan , Christian Brauner , Yang Shi , Vlastimil Babka , "Liam R . Howlett" , Yun Zhou , Suren Baghdasaryan , Alex Sierra , Matthew Wilcox , Pasha Tatashin , Axel Rasmussen , "Gustavo A . R . Silva" , Dan Williams , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Greg KH , kernel@collabora.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 15 Jun 2023 at 16:52, Micha=C5=82 Miros=C5=82aw = wrote: > On Thu, 15 Jun 2023 at 15:58, Muhammad Usama Anjum > wrote: > > I'll send next revision now. > > On 6/14/23 11:00=E2=80=AFPM, Micha=C5=82 Miros=C5=82aw wrote: > > > (A quick reply to answer open questions in case they help the next ve= rsion.) > > > > > > On Wed, 14 Jun 2023 at 19:10, Muhammad Usama Anjum > > > wrote: > > >> On 6/14/23 8:14=E2=80=AFPM, Micha=C5=82 Miros=C5=82aw wrote: > > >>> On Wed, 14 Jun 2023 at 15:46, Muhammad Usama Anjum > > >>> wrote: > > >>>> > > >>>> On 6/14/23 3:36=E2=80=AFAM, Micha=C5=82 Miros=C5=82aw wrote: > > >>>>> On Tue, 13 Jun 2023 at 12:29, Muhammad Usama Anjum > > >>>>> wrote: > > >>>>> For flags name: PM_REQUIRE_WRITE_ACCESS? > > >>>>> Or Is it intended to be checked only if doing WP (as the current = name > > >>>>> suggests) and so it would be redundant as WP currently requires > > >>>>> `p->required_mask =3D PAGE_IS_WRITTEN`? > > >>>> This is intended to indicate that if userfaultfd is needed. If > > >>>> PAGE_IS_WRITTEN is mentioned in any of mask, we need to check if > > >>>> userfaultfd has been initialized for this memory. I'll rename to > > >>>> PM_SCAN_REQUIRE_UFFD. > > >>> > > >>> Why do we need that check? Wouldn't `is_written =3D false` work for= vmas > > >>> not registered via uffd? > > >> UFFD_FEATURE_WP_ASYNC and UNPOPULATED needs to be set on the memory = region > > >> for it to report correct written values on the memory region. Withou= t UFFD > > >> WP ASYNC and UNPOUPULATED defined on the memory, we consider UFFD_WP= state > > >> undefined. If user hasn't initialized memory with UFFD, he has no ri= ght to > > >> set is_written =3D false. > > > > > > How about calculating `is_written =3D is_uffd_registered() && > > > is_uffd_wp()`? This would enable a user to apply GET+WP for the whole > > > address space of a process regardless of whether all of it is > > > registered. > > I wouldn't want to check if uffd is registered again and again. This is= why > > we are doing it only once every walk in pagemap_scan_test_walk(). > > There is no need to do the checks repeatedly. If I understand the code > correctly, uffd registration is per-vma, so it can be communicated > from test_walk to entry/hole callbacks via a field in > pagemap_scan_private. Actually... this could be exposed as a page category for the filter (e.g. PAGE_USES_UFFD_WP) and then you could just make the ioctl() to work for your usecase without tracking the ranges at the userspace side. Best Regards Micha=C5=82 Miros=C5=82aw