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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 146C6EB64D7 for ; Wed, 28 Jun 2023 08:33:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234462AbjF1Idu (ORCPT ); Wed, 28 Jun 2023 04:33:50 -0400 Received: from madras.collabora.co.uk ([46.235.227.172]:32772 "EHLO madras.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235465AbjF1Ibj (ORCPT ); Wed, 28 Jun 2023 04:31:39 -0400 Received: from [192.168.10.54] (unknown [182.179.162.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: usama.anjum) by madras.collabora.co.uk (Postfix) with ESMTPSA id 52947660716D; Wed, 28 Jun 2023 07:03:51 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1687932238; bh=Mnlsggp9LUoS8ve7lv1HuoaS0bmkESWlf5OUJi5Yvkg=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=mtwgShxLJXCcwEam7M0PfR4SvBpDh8abUYPjYTamu74SIzmR2joyzzavKdoArvNuB nRSob2PXk934h4fvu2vLMtqfmEH257l2n5sSuLNTcht9AjHnEBIEA4X9b2iD7s6Kdp oyLtdDgOsFk1pwIGepOZCkT0WiuzwivKJVDQ1pZ9WzWzytIRWyhufS6hgn6UVTSys+ iwH9DPNXEw6t5FZ1bKlSPXEBxg3jTg4miZptd7d63NVeFHuLTYhcpLhpS84vbUnX0w IlsCZCstDQQ+LinINZe5gE5lY2Il64nYqc4HtIPtZludnhDTh9+qzMIbtaBDMR836V y2vShbeIgCJvQ== Message-ID: Date: Wed, 28 Jun 2023 11:03:46 +0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Cc: Muhammad Usama Anjum , 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 Subject: Re: [PATCH v21 2/5] fs/proc/task_mmu: Implement IOCTL to get and optionally clear info about PTEs Content-Language: en-US To: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= , Andrei Vagin 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> From: Muhammad Usama Anjum In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On 6/28/23 12:54 AM, Michał Mirosław wrote: > On Tue, 27 Jun 2023 at 21:20, Muhammad Usama Anjum > wrote: >> Thanks Michał for replying. >> >> On 6/27/23 11:52 PM, Michał Mirosław 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 AM, 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 address? >>>> >>>> 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 != end). >> Nice idea. But returning ending address in len seems a bit strange. > > I mean that it would update `start` = start value for next call' and > `len` = `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). The `start` and `end` with updating the `start` with ending address seems most appropriate. I'll make updates. > > Best Regards > Michał Mirosław -- BR, Muhammad Usama Anjum