Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230626113156.1274521-1-usama.anjum@collabora.com>
 <20230626113156.1274521-3-usama.anjum@collabora.com> <ZJo/gOnTmwEQPLF8@gmail.com>
 <13ea54c0-25a3-285c-f47e-d6da11c91795@collabora.com> <CABb0KFGn=3oAYa+wsf=iWr1Ss=en9+m11JOijEibXJLFDAkvjQ@mail.gmail.com>
 <6ac9c60e-0a6b-110a-cace-97afbd9708a0@collabora.com>
In-Reply-To: <6ac9c60e-0a6b-110a-cace-97afbd9708a0@collabora.com>
From:   =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= <emmir@google.com>
Date:   Tue, 27 Jun 2023 21:54:25 +0200
Message-ID: <CABb0KFH60U5RE9dLfCOEGp5=wLwwxpKaMdzQL8drYEmL3T_itw@mail.gmail.com>
Subject: Re: [PATCH v21 2/5] fs/proc/task_mmu: Implement IOCTL to get and
 optionally clear info about PTEs
To:     Muhammad Usama Anjum <usama.anjum@collabora.com>
Cc:     Andrei Vagin <avagin@gmail.com>, Peter Xu <peterx@redhat.com>,
        David Hildenbrand <david@redhat.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Danylo Mocherniuk <mdanylo@google.com>,
        Paul Gofman <pgofman@codeweavers.com>,
        Cyrill Gorcunov <gorcunov@gmail.com>,
        Mike Rapoport <rppt@kernel.org>, Nadav Amit <namit@vmware.com>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        Shuah Khan <shuah@kernel.org>,
        Christian Brauner <brauner@kernel.org>,
        Yang Shi <shy828301@gmail.com>,
        Vlastimil Babka <vbabka@suse.cz>,
        "Liam R . Howlett" <Liam.Howlett@oracle.com>,
        Yun Zhou <yun.zhou@windriver.com>,
        Suren Baghdasaryan <surenb@google.com>,
        Alex Sierra <alex.sierra@amd.com>,
        Matthew Wilcox <willy@infradead.org>,
        Pasha Tatashin <pasha.tatashin@soleen.com>,
        Axel Rasmussen <axelrasmussen@google.com>,
        "Gustavo A . R . Silva" <gustavoars@kernel.org>,
        Dan Williams <dan.j.williams@intel.com>,
        linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
        Greg KH <gregkh@linuxfoundation.org>, kernel@collabora.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, 27 Jun 2023 at 21:20, Muhammad Usama Anjum
<usama.anjum@collabora.com> 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
> > <usama.anjum@collabora.com> 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