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 CBD97EB64D9 for ; Tue, 27 Jun 2023 19:54:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 33DA58D0003; Tue, 27 Jun 2023 15:54:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2ED718D0001; Tue, 27 Jun 2023 15:54:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B52C8D0003; Tue, 27 Jun 2023 15:54:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 0C46F8D0001 for ; Tue, 27 Jun 2023 15:54:41 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C469D1C849C for ; Tue, 27 Jun 2023 19:54:40 +0000 (UTC) X-FDA: 80949580320.18.4A1AEE4 Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by imf20.hostedemail.com (Postfix) with ESMTP id D1F1C1C0016 for ; Tue, 27 Jun 2023 19:54:38 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=2GlDcJSR; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of emmir@google.com designates 209.85.208.52 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=1687895678; 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=oyMtR3cHIPCcrX9Qmw6TUS4exz//e0byqhk5V1sO8fk=; b=e/wpBZCUpgZMuz/8IjCLXQFW3ADhdnUOyV5kwSWEMEwCgNi2+OAZVt5EJul4btfJrROM3r PTpbSOOdOKFAFhQcbJDIcl8yJUKmTe28u5B08OjR5P3+62/n2sV/UdS7Nz5v6Cxre6Gxin YIvnEYaM4I+bNxwNZAIwJCTIPONGK9I= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=2GlDcJSR; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of emmir@google.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=emmir@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687895678; a=rsa-sha256; cv=none; b=ZHgQ2HXYwj2Efqf8Y4d+LGNvUJYhRXwQ3amSZ7naT/Efs60b3hZbVTH+moqZp5ac7IKE8T lfOin5/sYMA08j1Xee1RIrP8Q5G9xvW/VTMQuwp5oAlR8scyQZGYoZM9G1B9hIKBCpGD+z 04eXDqKVsZKZb7rtmW45XBiU0unMvmo= Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-516500163b2so62a12.1 for ; Tue, 27 Jun 2023 12:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1687895677; x=1690487677; 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=oyMtR3cHIPCcrX9Qmw6TUS4exz//e0byqhk5V1sO8fk=; b=2GlDcJSRb8Sf7QlZ29iJIG113UXKJ0k1Wa9naaey4i1af+jilqW5+4dt7o2PUwztP8 qSwhqP/3oTAgRj0AcQRNlWBPWJ/huQLNNufJFTIVfvw/jV8xfn/zaSooX2E8S9liVWrD /Km2uLvQvF7E79fOyLLEs8VnIJayGbSyUZEXnMTNp3qB5UVTWVLOzDATNPiM2cwsGr98 oNYmb/B4B4hF556uRQ5jbj3dR3wtEHyyqVJ3tMNLCNxGc/qRbLE4qlrv/z5nLj04TwRm DyH9PJxxM0BA/Iz2E2HgJuGE5E7bvTC1ptTtc5lwuC7OHDm7ZeK51zGvoD4Hvwe0iaSd KljQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687895677; x=1690487677; 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=oyMtR3cHIPCcrX9Qmw6TUS4exz//e0byqhk5V1sO8fk=; b=SQEPQAkjnoH1xL8Br7qjZrt9Bq7+zDuTIkEYxkLnw3jwQeWILvXjFoMXJx7lx0gQqk dMwklo5sZ0AndFUvuVFe9MNF3J57AmKvgoxytrQzgXcHrUJ7jcmexQ8O0a5FVrA+2jNJ f6eCLuOWNKP5J4Edj+mmzil9MgVpYoexRD0ezQiHZcwCNwszMUqmWlS5QiH/rHZs+7mD PB+vNd2zmKXeBYnIcAX+54K6rh0kxYoJB4E8KUvihFOII3y23SLLX1N1xLT5QKkIG5HH Y5RXsqGgxcRs236d+xb3jHYLqOVWFzHMadf1+Al74B+fPFGydkO5toaSylRfaptLL81L ArpQ== X-Gm-Message-State: AC+VfDz4JX7VDZMtgzCcF9xOrxLLZn54QrP+lwiXI8KJKXLtYDUk289j /IBU9Iif9z/nNdZxRJGhZdI5tbDBsakmsB99Gwc5JQ== X-Google-Smtp-Source: ACHHUZ7raH1oUkiTxXalrd3pGeyqiAo4JUItij8HXQEL4Vw/n53rYAlsyi7qb4LsO/833WErhLsHUeBIQPoP/qWP1aU= X-Received: by 2002:a50:99d0:0:b0:519:7d2:e256 with SMTP id n16-20020a5099d0000000b0051907d2e256mr14597edb.0.1687895677218; Tue, 27 Jun 2023 12:54:37 -0700 (PDT) MIME-Version: 1.0 References: <20230626113156.1274521-1-usama.anjum@collabora.com> <20230626113156.1274521-3-usama.anjum@collabora.com> <13ea54c0-25a3-285c-f47e-d6da11c91795@collabora.com> <6ac9c60e-0a6b-110a-cace-97afbd9708a0@collabora.com> In-Reply-To: <6ac9c60e-0a6b-110a-cace-97afbd9708a0@collabora.com> From: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= Date: Tue, 27 Jun 2023 21:54:25 +0200 Message-ID: Subject: Re: [PATCH v21 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: D1F1C1C0016 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 3crqjpcuhwjzgeqac4wb9rauu6wtpcyj X-HE-Tag: 1687895678-962669 X-HE-Meta: U2FsdGVkX1+O9sYEUv/XQ046EMfberWzsHjyPUeliEVt4RnbkfOh6DdZC8FuYZmhxq5p35voy6Uhr24kRkfyZe6JqoO13v4ksmgex7bNeTHdasy0TD8SszD2ZqCrSjzQG7kLZdV49erXQrvr92zhoQKr1sTU1lMPw/s6cWBvOxjfGHjgQOUpcaBO1rVyC6NqwXJ5tqp7BxdWJyaQPW6rpXtiiL1uKd7IUC6iBlIjupu4QGHwE+RGdBRai+yxTqqgVk280tr51uT0xnObOfa/JsnG1/CYQm3al7fK7D0vJdDP2ozWPSBUMCvAmQ+3ls1aNaLR/U8274SjTm8+4FKKqyh8wF/8+XCKP6eTLWhKQbUHdeaV/WDJphfZMK34H7nD3eMpu9R4oXACvTX54VXAIjPE0P84xbSJkQCUzTu6FRjYhEnIKvOBcOkwFAr8KFtHmwVzbXsWnDzM7kLddfSAb8abeSLhjMWvCWIt/Hn20opGHceTGwl4MKAIE0XOWGBRUjOycalxyPzmDKjt4v2TM+VxFGkgBDqhRblGB94xlcxDkjDQLw89QoAMFZBfh6oob2iAuFBOUaDYb+drjgczZJB4h85WBOOgOGDvdWQyRM3BX1s2Mgx375TPaGSE00pmpgbfeAdmIhMNVpsLC+i8Fiay/WwN5daM6DAi02gMY0f49AGo+qlgz21gYFllUCAeAP8HylDrZu7Mn+30fDGRLCL+lBY4e+vhV7pDM9r78j3JqOecIknTupiRVjAzdrmsOg3yiZ8wSoacFtrbm2FvN2EdlbyeU7v2BJ8qbRTS+xbH8nFmx70IFgQ8XaWvZmWRshL1t3Jguz0QtGC+dMMVJCuvEyTtqNsW9dJrQc1XX0qo4uiPoxk+s6lFckZhpLUf4g4Fjwnxo8K+0Q5oJZEcEUf2PvHJRat7gtR4gHYZK7tX94LfFzFVuAdRC694iBV4W3qQZhGa0bws2BJ+Qff OpLl7XgO Fsio4A8XKOyW2mY11dUTS2OzOaY5obE9p123w9w8t21WK79LwWsXFK3A/zbIfx8CH+5XY1AOGvb5NvXybTpmML487lPSrcd1iZPaTRRnY+IiQwmp35a+Zq81t4hja3MVTRCymoeKLDgx2c5o5Of8yPxX5PmLsFclVcMjysBeFW0r37GBukhEZE2Co2TLMG7SbzY8hDT8uedxfVN2ANEZotX1FdIDQXBVhf2GZpnnI8qrb80Cuz7weaHU9x2wY4Rs6srcj7GlO8oucCsDdTU2TcXWJrd3J/q4ksKDJEnOeYQWtCL4j8OuzwgbfP/Se1qxSAF+XSQtRl7X/aMoeqM2IR91DeFiqHz6BhsP7XTdGKiS+oCQ= 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 Tue, 27 Jun 2023 at 21:20, Muhammad Usama Anjum wrote: > Thanks Micha=C5=82 for replying. > > On 6/27/23 11:52=E2=80=AFPM, Micha=C5=82 Miros=C5=82aw wrote: > > On Tue, 27 Jun 2023 at 11:00, Muhammad Usama Anjum > > wrote: > >> > >> Hi Andrei and Michal, > >> > >> Lets resolve last two points. Please reply below. > >> > >> On 6/27/23 6:46=E2=80=AFAM, Andrei Vagin wrote: > > [...] > >>> And we need to report an address where it stopped scanning. > >>> We can do that by adding zero length vector. > >> I don't want to do multiplexing the ending address in vec. Can we add > >> end_addr variable in struct pm_scan_arg to always return the ending ad= dress? > >> > >> struct pm_scan_arg { > >> ... > >> _u64 end_addr; > >> }; > > > > The idea to emit a zero-length entry for the end looks nice. This has > > the disadvantage that we'd need to either reserve one entry for the > > ending marker or stop the walk after the last entry is no longer > > matching. > This is ambiguous. Can you explain? Both solutions would allow to return the restart point back to the caller (the second one would need to stop the walk as soon as the matching page range finishes -- that creates discontinuity). > > Another solution would be to rewrite 'start' and 'len'. The caller > > would be forced to use non-const `pm_scan_arg`, but I expect the `vec` > > pointer would normally be written anyway (unless using only a > > statically-allocated buffer). > > Also, if the 'len' is replaced with 'end' that would make the ioctl > > easily restartable (just call again if start !=3D end). > Nice idea. But returning ending address in len seems a bit strange. I mean that it would update `start` =3D start value for next call' and `len` =3D `len` - (new `start` - original `start`). By replacing `len` I meant to remove the field and add `end` instead to make the requested range use begin .. end (iterator range) style instead of start + len (buffer and length). In this version you only need to update `start` (or `begin` if you prefer). Best Regards Micha=C5=82 Miros=C5=82aw