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 10185EB64D9 for ; Thu, 15 Jun 2023 20:00:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7A1AA8E0001; Thu, 15 Jun 2023 16:00:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 72A306B0074; Thu, 15 Jun 2023 16:00:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A41A8E0001; Thu, 15 Jun 2023 16:00:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 44B686B0072 for ; Thu, 15 Jun 2023 16:00:20 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 03D031C889E for ; Thu, 15 Jun 2023 20:00:19 +0000 (UTC) X-FDA: 80906049000.14.0D10D7A Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf27.hostedemail.com (Postfix) with ESMTP id 11B4C40008 for ; Thu, 15 Jun 2023 20:00:17 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=r8b1n9Zw; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of emmir@google.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=emmir@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686859218; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+RWqrzTlZYe8/Gfpdw2HrcNGicUcMl9+E9jN4a7pTg0=; b=MfZzgZSkETsOSDt8E07ijgpLGUdYDqtu5geo+1JVv45DQxLj9JKzogC9ZRag/6zbzIksPk wYDXfTfjxwZK78dQv2+5789Lml1eTUqUZ/zy/VpzxXjB+zLxzQeCWHvO9X+Gc2MrbS69Fj CFuFUbXXjRMEyoUoddwDmbcknGslDE8= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=r8b1n9Zw; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of emmir@google.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=emmir@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686859218; a=rsa-sha256; cv=none; b=l6B3za6DDHpKZ35t6K8wTuy9BUYIjaJqSVqXtFW44GpJnxxapN0vY8gXeYZB5Q5zRAHw7/ lqXLFVySs3sW5LVtlqbGhAfk7vyAHU2QyS4oQ3DMRRRvGbanddhkhouJTEQ8Z6E0T/ySaC bDpNUpD+Q07TH/ZyWWnZHEQwtw5aDqY= Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-516500163b2so303a12.1 for ; Thu, 15 Jun 2023 13:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1686859216; x=1689451216; 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=+RWqrzTlZYe8/Gfpdw2HrcNGicUcMl9+E9jN4a7pTg0=; b=r8b1n9ZwhABfsIVwNrOC+42qy+6eKOYn88GRmm5/860S+dOA70/GmS+MgS6xsMu8Dy U7CEjqWFIT5C/GKLEtTwTjzUmds0heLEdHByLQeDqGqa7BGMfnrdciyjCH9beLdxeUgW OMbz4q5EZkoHPmwl9Z/mpvg4v77WVolcyjGqiEqNgidrU8n44T48dg4yBjV4oEURlVEA uE6OvmGJKphObmjGKcEj3YSZBs+pShjnTUDpiMtWCfUWStekfQKoIQ7WCYH6HgkdVQl+ 7gNTpWgRF9tnJfJKjb8M2cZdiPfiZYJ5vhALMc1BWoJoL7g+5WKhC9/YkwkbvAL6r1Yx uGGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686859216; x=1689451216; 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=+RWqrzTlZYe8/Gfpdw2HrcNGicUcMl9+E9jN4a7pTg0=; b=U8lavC5IE4LdvcyYHS/jkS9TBKkDmBEF7Ld9ytpNyHAAtz9uSpXllXF18hUOFNpHGF T0kW1zk4oTD0sW9ryXi4OOSkF5RMUaFjN/mSoCkaw50A8BCSe8nELsMWi1pvym7L1K3u ZfKvHpEQ2QLqgjAtXh/Z2oe13BOwAYyVo754iUnAjsMzXEBQKyCbiUbrIgtdasV+dT3Y Hl7yBmNc/XkzGF7XH4AsJDV9zaUbyRupOil0rYAWjlXo60vvJ3zJ5Dl8gjscN/ONk0sT yMhHUzyH3rQpbaOQaZcX9QmbZSAnRxMIwhkpPtv3zU8S89EV4e1Q1D2zmwMU2NGmQhWj J4+g== X-Gm-Message-State: AC+VfDz1x7lNSvf9Y2ttLJMEaDdZ3KyLQhysBa5tQBqI171C4WfO2a8v 9D52Muimn6iMhNkXtzb1qUZkozVP/+nusJPxImedJA== X-Google-Smtp-Source: ACHHUZ59IUn6ONdci8fY72qJ+fprLwkmaLiabWTmH9HLJPn3BDB2NQeOO/TEIF/PybYaw++bw7+gWImgKfMD6QqIj5s= X-Received: by 2002:a50:bac3:0:b0:506:b280:4993 with SMTP id x61-20020a50bac3000000b00506b2804993mr128656ede.2.1686859216245; Thu, 15 Jun 2023 13:00:16 -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> <43c96533-8009-e42f-721c-4b2d1e142f5d@collabora.com> In-Reply-To: <43c96533-8009-e42f-721c-4b2d1e142f5d@collabora.com> From: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= Date: Thu, 15 Jun 2023 22:00:04 +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 X-Rspamd-Queue-Id: 11B4C40008 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: n3u1z9fqbsm8apr41otwxsqmfdykkpsi X-HE-Tag: 1686859217-421213 X-HE-Meta: U2FsdGVkX18GRZL/ZZXOgKHN8OsfLbOFTluyLQhJboPZOi93Ge1D15ISGI9t4e1BsEdhla6m36CE2moyjJk+4g5w27fpFNkZSXvxUjmmEd6LuFQgLNa8KJie36EAM5Dy62KYvybaOG7YQXwlUIYTcNhkiPJgujEoY/5zcQRS1mk7Xuk71NGC+TnNZl91slCqPFaPfiGvfVMcNJdBwG08KYBCQiBPc/okwVEzM2YWmdWseunR5F1PTfsm1Ivp0/TCI4YZTaK63OXGyez5HUvpVO9AFODnHUYCBSNQWwuTsvRmylJXCdwz6TZO4ngpCp1myvTveotm3kiZ7wkt+H0NrczUL6Bw3wXu82DHr586jaS/72huJ5Fa20t2m3qO2HHy7GZFSmhumyBH6q357bjpIhupSle/1FF3Oi1/s21NNvP2mRMgh75kkSTtkJGfDUAWdMgWMF5JF9SdZIUssCZX/bGuW7wB47LhOqVK65h8sbzdftOu5/lsRjW5VCQGJV6msQIDkHrwr8KzA0NO2rUMKTgXhBdBsTKufHmNv2g8+TBO50Se7eN2lnrDlrTUyj83tSJjCLWYaPD3+gg7L2pU/wUgu0H9r7A9JscQeItl58gNpEcaiUAMoTy4Fx0kYLyZ03tyWhaeDL583Vm3kp10rKpuhAyER7IRbl8TFTqL6zTVtVaAZQcChfNmSoqXpYBnjqQJJYea1pcJd0gaCezlsLBacWIl7vrU8FdZLIaUdd8EQxuDGzguPryAlY1N1Osnck8LO6VIHqsuCmr63cohzxk7XhVkLOgHZYVX7hyIt4m2qlIYHjF6soeZdA3YcGmHnY6tf4xFnpGg5AHx+JA7CAQ9JUXEWt70691HX41Ezf5wqVvJ1cyjjeaqqTtzJLxqyq8+6xKx3egygWL8sRtM1CiQjlJoZtE5pSgpmePb5mncGV3p7CDGKHggcahhNMuSVkEjJ2P6tL+EE401j60 qT7WB2Xa fjpb8iSsFRPEAXoxQBs7A0a2/reiyExKwdS3w6ouBDyUDC4+tJXNNVHxEaKUdiqEU8DYAG5FvvY0UUWJJ6j9YVli93omhy/+a0IbXumue0LzucprTFtKj2f1zbm5yRP89UFQ953JMrgrTR65JX6Ky/4Bss+IST1kJ8lOQ2BxXhoZqf0Ma4UgEF7xLwjPfeOmgOYOf3+p2jfMBcrMPHMsh0A0ovESlWyu7fnDhswNcI1TyVLzAu7PInzMLtXKZbpzE1c8jat3e6g4QpqUtAyLUy1B3MKTY62PVc5D5Xdt3vRB3xvxgXTYnLlhvcRAXOVBGh6YAzDBxZnsjTGiOcDYxg3JVJOrSYJjt9MwcJvoLRr7bChmYBm5VABZedYPeSwSvG95t 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, 15 Jun 2023 at 17:16, Muhammad Usama Anjum wrote: > > Please review the v19. I hope to get your reviewed by tag soon. > > On 6/15/23 7:58=E2=80=AFPM, Micha=C5=82 Miros=C5=82aw wrote: > > 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 v= ersion.) > >>>> > >>>> 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 fo= r 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. Witho= ut UFFD > >>>>> WP ASYNC and UNPOUPULATED defined on the memory, we consider UFFD_W= P state > >>>>> undefined. If user hasn't initialized memory with UFFD, he has no r= ight 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 whol= e > >>>> 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. > I'm not sure about page category. ASAIK the current check isn't bad when = we > already mention in documentation that memory must be registered with UFFD > WP before using write feature of the IOCTL. You could relax the (documentation) rule to be "WP works only on ranges registeder via UFFD for ASYNC_WP". That way you allow people, who don't read documentation to shoot their foot, but don't block people that know what they are doing from exploiting the nice feature that they don't need to track all the WP-registered ranges calling the ioctl() for each one and instead can just call it once for the whole address space. Best Regards Micha=C5=82 Miros=C5=82aw