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 59973EB64D9 for ; Tue, 27 Jun 2023 18:52:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E6418D0002; Tue, 27 Jun 2023 14:52:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9963A8D0001; Tue, 27 Jun 2023 14:52:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 85DF88D0002; Tue, 27 Jun 2023 14:52:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 732098D0001 for ; Tue, 27 Jun 2023 14:52:45 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 249814093B for ; Tue, 27 Jun 2023 18:52:45 +0000 (UTC) X-FDA: 80949424290.24.21F8C9F Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by imf05.hostedemail.com (Postfix) with ESMTP id 4475D100018 for ; Tue, 27 Jun 2023 18:52:42 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=Lwjol0Kz; spf=pass (imf05.hostedemail.com: domain of emmir@google.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=emmir@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687891963; a=rsa-sha256; cv=none; b=FuDvnOgajU7RboLBTnT6HHMSrd9NKifpUxXUq/8kFgapKcV7Vu0atWCCblOWhykh6SDzbY 80av5WGycomrhU5E7Vf3dIlH4TCKPKx8vq5hbhkMi4cAlJ8aeY7cYsTB0Fi91aY3GvCAIF W0DsJgFG9Dg/9Jgb0eP9fcOSXHLX5Uc= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=Lwjol0Kz; spf=pass (imf05.hostedemail.com: domain of emmir@google.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=emmir@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687891963; 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=zrMUD+bzjYq5U/OlRQ46C95vvZ+AhNRjqJFLfHa8n58=; b=agx7GtQEmhuS3sbvRpyo11TlLSZDOmmZcpR7v7MY47pfCn9u01ssyveRkvZHkna7IOCeat KrunldO8SN9++IqSE5YyRRf9xnKJt4ibglgE1BmEuPAUG3s0YAYjH3kCOiEOF3iWwfaYc1 cH0rKZleXunsfbV/krfhLql3tp9kFaY= Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-51d9372f027so1898a12.0 for ; Tue, 27 Jun 2023 11:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1687891961; x=1690483961; 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=zrMUD+bzjYq5U/OlRQ46C95vvZ+AhNRjqJFLfHa8n58=; b=Lwjol0KzgSFyHrtVjCTTjkFPYma+RQF77JRbL0wBs9NJOySx0p1L2f3KoQOq2wtYew bTbS4LUyDDLndkY34CBSLWvRzEdphSFvMUqTZGeF54WZZxThj2qDyI+xzBCFM4pogR7W 6bazPitMsZvcEA2YauBwiyijlOt2eO2AU6tgt0np1VbzJ0e1mNjUm9eEqWYW+z1kIExA Z01Z8niT6EkjqiZzq1atZgnkgvSbxGXUcTwbQbaWqN4xOUMT4xyf3shnyJrljigB3h2A KL/F/itIeavYuh/huelf/SLkHAf8a+Z3lf6f75s5Rw9smZoquAjZxv8gONeapQ66QuF+ fv8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687891961; x=1690483961; 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=zrMUD+bzjYq5U/OlRQ46C95vvZ+AhNRjqJFLfHa8n58=; b=ZtkDqeUhrem+/MG72UQCoIgvk80aDtp8MqbVceBj/g49U+Hf+9ZZ4xGIEPusreINrv gLs954iOHJI5TXm2VbCMEMq9pc8Qk8AAjLBrnpeEDl47PCMOvVOqPOWlKx8QT+osihQO RTMGOKOadoEVjkQ89vq7XMQxa+tbY5VUD9FLAz/0HHj/kKkb0WfJFmyRZuHkyUcE31ec rsQIi5sjsopcHbeWno2CysZyi1lDjZcZGLLZ1Ma7FKG1KdSIvcmZ1fgRbYOMZPsM+Y83 kttuGS1EnXWWZRpeSIN8TQBYhLH4WYaYi8b5l2HAVcPxsKTgZ5zfMsM1dqQbKr9N+msO zu/A== X-Gm-Message-State: AC+VfDzgm1bBzKkaaddfbzAb0dHeQs5nWDGwqz3MfXVP1q+Iow/M8BjP 4q+WdLrOmZ0WhuVBmZ20gjZTdnLWo2TCSsbm0IJ1DQ== X-Google-Smtp-Source: ACHHUZ4NqtygUkoF7LzNQuMwk4m82VidiZ4IS+yy+S4o+fhpUQ0AL4Z3k4FCruDAhBmmEv8MVBz6pucYVp9kK7qXtpc= X-Received: by 2002:a50:a6c3:0:b0:506:90c4:b63b with SMTP id f3-20020a50a6c3000000b0050690c4b63bmr12556edc.4.1687891961572; Tue, 27 Jun 2023 11:52:41 -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> In-Reply-To: <13ea54c0-25a3-285c-f47e-d6da11c91795@collabora.com> From: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= Date: Tue, 27 Jun 2023 20:52:30 +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-Server: rspam08 X-Rspamd-Queue-Id: 4475D100018 X-Stat-Signature: zmy7dz3fgjtc9pzctwnzeoseeksc4ogm X-Rspam-User: X-HE-Tag: 1687891962-42902 X-HE-Meta: U2FsdGVkX18AFJsnDd2xs7wkdXO8QLFbMzz1VycVHW+TW8+UiGhvkttnYQfV33/pupyg6fb9qZGSfYEsBonpbCJItCdDnFyvalDuUI5XXMUtivYJEYk99ZX3hjPbVrGAc3uTl+INk2LP+cRHtHhSmp6qms58dhYqJHJ+87gZc9dAyDcVDEEPL73P6sVmPUe5RjUJOrs+WiEColke7qg0EiGlwS2HSZtnRPkRjwZKfWnqaKNJ7WNmsiGF8n0P2jd457H0ChWLxRemtobWPcD5qdN37eYdTWaae4kSf0B/9mXgFz3u+F8BQWKaB2NnvkBxZh4qBRj2yKLum6bKMt6rGhfsRDuosMS66+UI9njCX4YWbafe5yaRQmJHqiNtYkEwhqxt2CWc7v1ViApyNPtsYIiY6Uet6dUb+jHYwS5JAYsx5PJrA6H2a+g/qGjwixg63Z57g0klSn0ClDrvkQ8IirGZDIxpAmTI+yZ0ENHZ6Le42pakkvRUBQP7VLjcpOkqtA1nOsQrNmZ3agGufzZUOFpZaTef5/wab/m8lYzH/MeE51tlzDGtnrogYyi3gjRH9DqFaUH7boaiZnykQjppdL57cR0nTagJnmG+Tt+59nneoTQifwLlBPvaLMn7kqqIfhxoFbFM0lLLPIfwy+v3mQz8QPHPbRgP5TNmucd402NEfs4KyLPiQ7biiOBEULxxHhhbZApHCq972M4ECnHurEp9eChSNPzaNCdF279T2aNW+eqU7/7uJrqH2YIOQ8R66CaWis4SagRhFE6agSoG+lKjGxBIuTEcG30xQOPpmjbSKWB9slopNs510sYBprdbU1GJ3Toz97uuTeM91s3vHQ+C1/jD7iOqu2y6CiXRk1A+PySP7XDaI6DnAHmYg6ysX19AWlSx6eMPgtHP7yZK3Dd41Fbuls7QoJLEwIah0UM9rcGa+fvU9obNoQ50T/a4bQ/Bx8wYhuh5zcMb09p uQYkFaLi XHIShZ4nByLJ7JsXKUe3ct90K6w9HMOntAYWBb4Yd5q/n8bLpmMquXoXw+GGWPHLv8j3aDQiJ4nUPWy2iicHYC05eSKPQQ7ZVsgAGvsfYX+YU9SIWeCl9G8zkFAAbfOjXODxswSZ0RZidXe5QsOkyxR2V/8DEehBNQma1Qqw33b4eCfdFvNk7aa4o6r123DsPexM38lc02Trm8fjWrBF+A47x3dUt0a6ghUBIguK1EZt7DCD5/0X1u07M2IkrYw/dqUSn7RZFdUBgNHCdrQ6w/QUmCRs5AFpA3DLTjYKKuvF/LB9aVhgZRoVS2P6mS65j55A76Dps1AysNPBk9JOjT7jmlGmy6dFGdacISNtYJ9UvN1Q= 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 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 addre= ss? > > 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. 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). Best Regards Micha=C5=82 Miros=C5=82aw