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 69D41EB64D7 for ; Fri, 23 Jun 2023 09:44:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EDDE18D0003; Fri, 23 Jun 2023 05:44:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E66B98D0001; Fri, 23 Jun 2023 05:44:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CE1D28D0003; Fri, 23 Jun 2023 05:44:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id B5CD58D0001 for ; Fri, 23 Jun 2023 05:44:29 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 72B3DA0DC0 for ; Fri, 23 Jun 2023 09:44:29 +0000 (UTC) X-FDA: 80933527458.27.333A797 Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) by imf18.hostedemail.com (Postfix) with ESMTP id 775D61C0013 for ; Fri, 23 Jun 2023 09:44:27 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=Kbr+ZwwH; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of emmir@google.com designates 209.85.208.42 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=1687513467; 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=uECgceGWceBpnEwgVEt1AFSmdXNTa/+8ZyNWq8IpWMk=; b=vKHYFCBPaLSUe15IJbn5Y79+ybQYwvRQPvTE7aSwDWnioc1v7sDRGe4LPhoxNgzx1wj6lS sQBqabzVJMXda9nzXZKu0r7iQVzgKELDOiZAiuAet+9SGLi5XoiMi2ZNLSlS521vNKwCoS tfvESBjDjeFM3cDB7keKYSogmJRVS+0= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=Kbr+ZwwH; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of emmir@google.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=emmir@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687513467; a=rsa-sha256; cv=none; b=hRWkoDxlBECokAv8Sw2sYEQdgNmQf/V7V50b1pTmUikER4cflh7lm0piNvbN8wQO36eHHE rc8KtFaFY3ADQ04nDLupilDmaMsiRvZE45FBWUTzs2+MNFYU0KUCo4A/uGqOSBA4ZgoNZB yfgAqWMf5Cud6neFWFehx+nfI6GZcIo= Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-513ea2990b8so8950a12.0 for ; Fri, 23 Jun 2023 02:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1687513466; x=1690105466; 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=uECgceGWceBpnEwgVEt1AFSmdXNTa/+8ZyNWq8IpWMk=; b=Kbr+ZwwHYHvA0TCLJ0MdIwK/ccEwxx5KSPma0dmAvQIY6kj9M5JLiT59I+c/izkmv2 n9pmwQxDJQNjmwworyPbaKeC3Ld8nQ4YzJQUl81n0uzJKWW+y1YBMTq+bAxjaNy+2Uk1 2+c6VxKT2l9oN0UJs9rmXFiz2wziDEW+FMecIVeRpyPC+3p6h7YtB2bWAnfvkjFG019s SvcL3SBhcYvAVeuiLFX4CwomKL1yZfd3JUWKnS/0/hgwcAMoHAZfCNAKfXwtIiCjg6jh Ae993CrxqBpmSq0aTmVtiKkCd/JgjSefymLwf4R5lFK8ec0c85cp6c0CFc3gblvcnhWa 1m6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687513466; x=1690105466; 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=uECgceGWceBpnEwgVEt1AFSmdXNTa/+8ZyNWq8IpWMk=; b=JNd2MClPBSFQ31MSz2b7fxetSjs6unJae+rCgLJmvzMGaMSMQVwhnGMuF4cB8LTsJy /Flhe7n7yA889gawW6GYsdB+yEQ0X1o9V/Kh9PbkilnJ9gwURmIVvxS8ZqBLcg/DYoys FGd5i0LoHSz6Ev0bN/uDxCAz4bHE4V+4F3DT05YdfY3XzPQLc8bwwXnsmbc6X52SxmLT 3hUY9I9avAb69Isgezw34moI+/2GEcE7I/GA37/HA9WfoHIrMeo3n41rBlejFDlA3c7j ff6rhBPSG6/MyVA+l/GHasVyxBV6bfpeuONM68ffAbznY+zwc4DnVi+9OWp5fQn3kTrD Wy1Q== X-Gm-Message-State: AC+VfDxgDBbe67kMDoI5Cgjjgr/KpfXYWd6M2F7K0q1Zi8pquFdaZ/+7 vAMGp6mU/YLzaSjMtdQlWWOMvLdRBIRPXj9xxrNZOA== X-Google-Smtp-Source: ACHHUZ6rqOZ455iJdXd6CS4M6p+mA/ZNKARrMmKzGjtlcQiR2QyldrbL8+MKATVwRLr7V20zWPJywlF1j6AsPkZ9OkM= X-Received: by 2002:a50:d08c:0:b0:516:6453:1b76 with SMTP id v12-20020a50d08c000000b0051664531b76mr51906edd.5.1687513465752; Fri, 23 Jun 2023 02:44:25 -0700 (PDT) MIME-Version: 1.0 References: <20230615141144.665148-1-usama.anjum@collabora.com> <20230615141144.665148-3-usama.anjum@collabora.com> <1c1beeda-ceed-fdab-bbf5-1881e0a8b102@collabora.com> In-Reply-To: From: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= Date: Fri, 23 Jun 2023 11:44:14 +0200 Message-ID: Subject: Re: [PATCH v19 2/5] fs/proc/task_mmu: Implement IOCTL to get and optionally clear info about PTEs To: Muhammad Usama Anjum Cc: Andrei Vagin , Peter Xu , David Hildenbrand , Andrew Morton , 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: 775D61C0013 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: z8f9jhzccrc631ftfightmmm6n36s3t7 X-HE-Tag: 1687513467-179806 X-HE-Meta: U2FsdGVkX18nGko215sJ8mlIW+oWamTCT54hD08R4uhCWJfpQou4Y6I/ex38CwQcNJYIS+M4bfySuMMQgINhpIgc9uyDlTcn2n63+GKioBcaKnpOxnJKum1FWN8fCt9nDnRlKnvpmVJwGOXZgWgU0WWTq9tgK7HxoSItOEnyK46Xpf9R7NSPi+HFDlMx/qxYlq99T4ZhgBUtQw+Muu5eM9Whb+xfSGQyUTTcFDWVJP0wcHUtnxbpxO3LOpIEqESN8Nj+u/9s+XIGmr4cBp/ECUS7aROEKw4D0o2oUMvBHIyANNLTwzktKlC653rSA6mEgjlpfHHj9n7Z2LjvyTFi7BrtBsVgEVxm9uETBFDRC45W9hb52/oZ8KC7vQ1Z+Te4d4UIGOZ+SRDqoiyDlYcOOssvZWWkXP8cQ8suZiD6FRY+jr48xp7B9oNQjV4pJG8CwI6ciKY7swH27SfzNHZHR7wU1TrpYHoOO1QZG6TujlCcI1wVkL3D0Q1SozzG1trDmjGUf4/Ze0/nRGq9DLinGA4lmlGDKz+RADW56BxHdSew2XWaLulI50m6DloDBEXbAoVKMhB9tsw2iM6oTa1rVzyrhAyhqZgYyJzPW7iFORX4u1hco+NJdP5j8He2fTTCqJJ8tTZhPsgcuEUjeXtuIOchEFZU3i3+maJ+VaFL//tt+gkY9LizGW6F2DZmYk6Ly8TbbzgM5csUpYI53Hq6sB2U6vL5/9V/XtOy9AjjlITm6EFoA0HJnC9aXyrTKBXeMszFlohQKhqOO8sq5n/kAgkF5EHwlEO/XUcpX0b8bb3G0Cu/weKnnzBAd/o43h5v38lcZlKtiFFIZecoN0A90i/5ylWTXEpTXAhhUOxjx+1VxNaoEvSge+6DSpCWHyxQA5YCmeKIrWmhkMCpkf8p/YW7zXllYE9QdRJLSFsnNNKU15pmi7P8JZFKjN3Nt+5p8jx8ppP5k1OdJDe1yyn NLppuSUy zposDAPYYq6jfbU6P30EETSoRteF0ghwUWVqptmVIreuJ77QYJT0hotlqZw6FguZZ6fwtuzA089OpIoKXeoorsR6J5V0ZEgbQrkqL8Cr31lT43K8RKVfN5UZlT8jJT3OYl107vlh0tZc8pryER5cjIUCvdg6biu794h0Ew05G0hJJvT16czob6VqGynP2rv2vE9C49lI0/x+/H8La8YlX1QLGSToMs0Y9vZU6qxZ9TYfbTrbCorUZPP8uhGLWsB0ogVAePgpAqw0vvxQlGjhJup2T3hp+fdEaBT9ShAaToFfuG9I7h1+g+EnFsjZWjE+a0v2B4WtthRKpq1ME7e+Fp51a3R7HhxqkHziKgdUjsU0PFV0= 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, 22 Jun 2023 at 12:21, Muhammad Usama Anjum wrote: > On 6/22/23 12:45=E2=80=AFAM, Andrei Vagin wrote: > > On Wed, Jun 21, 2023 at 11:34:54AM +0500, Muhammad Usama Anjum wrote: > >> On 6/20/23 11:03=E2=80=AFPM, Andrei Vagin wrote: [...] > >>> should it be PM_SCAN_FOUND_MAX_PAGES? Otherwise, it fails the ioctl e= ven > >>> if it has handled some pages already. > >> It is a double edge sword. If we don't return error, user will never k= now > >> that he needs to specify more max_pages or his output buffer is small = and > >> not coverig the entire range. The real purpose here that user gets awa= re > >> that he needs to specify full hugetlb range and found pages should cov= er > >> the entire range as well. > > > > but if PM_SCAN_OP_WP is set, this error will be fatal, because some > > pages can be marked write-protected, but they are not be reported to > > user-space. > > > > I think the ioctl has to report back the end address of the handled > > region. It is like read and write syscalls that can return less data > > than requested. > This is good point. I'll abort the walk here instead of retuning the erro= r > to user. It would be great if the ioctl returned the address the walk finished at. This would remove the special case for "buffer full after full page was added" and if it happens that despite `max_pages` limit was reached but no more pages would need to be added the caller would not have to call the ioctl again on the remaining range. [...] > >>> How long can it take to run this loop? Should we interrupt it if a > >>> signal has been queued? > >> I'm following mincore and pagemap_read here. There is no such thing th= ere. > >> IOCTL is performing what user has requested. > > > > In case of pagemap, its buffer is limited by MAX_RW_COUNT (0x7ffff000), > > so it can handle maximum 0xffffe00 pages in one iteration. Do you have= any > > limits for input parameters? > > > >> If the execution time is a > >> concern, user should have called the IOCTL on shorter address range. > > > > It doesn't work this way. There can be many users and signals has to be > > delivered in a reasonable time. One of the obvious examples when a sign= al > > has to be delivered asap is OOM. > This IOCTL is just like mincore, but with other flags and functionalities= . > Mincore doesn't put any limit like this. I don't think we should put any > limit here as well. I don't think we should treat mincore() as a good API example. Its interface has similar performance problems to what select() or poll() does. In this ioctl's case, we can limit the output at this end (large anyway) as it won't affect the performance if for x TiB of memory the call is made twice instead of once. (Returning the end of the walk reached would be much help here.) Best Regards Micha=C5=82 Miros=C5=82aw