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 C395AEB64D7 for ; Wed, 28 Jun 2023 06:04:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DA2E88D0003; Wed, 28 Jun 2023 02:04:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D52678D0001; Wed, 28 Jun 2023 02:04:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C1BAE8D0003; Wed, 28 Jun 2023 02:04:03 -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 B61338D0001 for ; Wed, 28 Jun 2023 02:04:03 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2CEAB40B86 for ; Wed, 28 Jun 2023 06:04:03 +0000 (UTC) X-FDA: 80951115966.11.BC5D1F0 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by imf16.hostedemail.com (Postfix) with ESMTP id 2C3D3180016 for ; Wed, 28 Jun 2023 06:03:59 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=mtwgShxL; dmarc=pass (policy=quarantine) header.from=collabora.com; spf=pass (imf16.hostedemail.com: domain of usama.anjum@collabora.com designates 46.235.227.172 as permitted sender) smtp.mailfrom=usama.anjum@collabora.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687932240; 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=6Q86n1mHk0BE6RgkRnw6hMZZbrZDijUwhzfBhT4vxVU=; b=Z4YvmUJn3EQVnZhhGhTiluVc91EdM0dIkVPQQ4miK3iCX8f40mD+6hn3dy0gTxh9Y5/ldK Re+SFXIerHY8v+t/a46df5T+TQOyHvzb6qV6P4wQYoXIxvImKEeRKCMLGpG6gAOoku1hFf vSpZDXutD8wJpAKF/qIov1gvMCh6Js8= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=mtwgShxL; dmarc=pass (policy=quarantine) header.from=collabora.com; spf=pass (imf16.hostedemail.com: domain of usama.anjum@collabora.com designates 46.235.227.172 as permitted sender) smtp.mailfrom=usama.anjum@collabora.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687932240; a=rsa-sha256; cv=none; b=8E9+1fQbHC/qeu2Cn6jxto/AW0OcJlODo6iad2if+OgXwzX6nNb6C9a7eosm/utzWi5Okv PBpHE+G2ISVKAs7ItMBH8FZKMwtSYgSJy+D/DHLx/bW6/hpMa6GQ7/vyR5Zco8GrbAxOdG Rr3jvMMz2lVKj6aCsoZF0MvMwqsVZWg= 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 X-Rspamd-Queue-Id: 2C3D3180016 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: rcqrpcgsqmk7scp9g4urj9mek9owecm9 X-HE-Tag: 1687932239-670235 X-HE-Meta: U2FsdGVkX18aq0vQFoy6Z6XJzgLV3L1uEuhgtkbDqWRJ7KdNle5aZvvTno7ikVVRc9EoIgbyapHzbvSyPf8xi9ulzu4VSLetUI9QCmCbIO++URQ8sXgCDDjJOWJMpdyOzSbWlI2Do6BofTFA/nZSmo8nkAYE9NlqKyzeo5avMlzZidhfVBFkLe2KbYoWl5PaA+/ilq0MqIY9ILYsHN++Hw/cKBvx+PHLOOc2dxZmxJJsFxV/Swz4cVmtuP/wz00UcGLn+0aaTGhI3/53exzMCsLvGlWaMq1O72YcWtY30jX853DwWtlj8TYtPoauAqModTMgngElcc7hlLXHhnCFAxMwIfb7x6LXMZweLE/Sx3ZHlt/pluGhsRk4jeuzgaJHhz+rr1DDyEIWQh76R3xFa0jKTTk1W+BNZuhHtYGJSNL9DD6DklQHSPTx55s/vLqf2T3XbSknMxTmsKvLcutDd67uV4Wl2Io2oz+Kjq2GDutX3K14udqFTpOSe+SRWbJXxliouBgdOeBL9pOkJNLAnD2gD1/Pv0f0pEFGsGWGQm3VjufzMCexnmpOnhAP4kvyPBCXBkht951A0ph5IhBH4x8XEjre4MicsgbIdbfz6YyXhPZi6JjawoXMAzxw3kcBBp/AE5omq60w44OsHtfRGRoPUhYW1DZgsg4uunOuC4qU7xp+1A4rUgNQL7wVFbVnK/BHJ4GLEAyx3IiBPHCwF8xl0k6BILlb5sulr9ljdqMyz2kGPsOn4WRKG4ZPc1cU1JDuuFoNDP2Fa7P/M518DGS3m2mKls6NbxfvENfP7Q6AScYXB3wFP9HrK8FvouFTX3hxU44WYBlwEHNioGfLBiQoLZL3y5fGWTmic866VizKur1on0B5PWbjWNbhOn4J1DHSC2lPebEENPE0lP4rWIhMTiigUAdz5P3DEDi683Yc5zxAAIB5dTYS9ZNNqE2oyt5GG4hZc2mFOcr1doT QCkAtjpj HzWNPrMyWdp8IEK19cfGGFrnJudPxtW+G+Ru78CGDwO4cV8c5X6MW3SjlzG4LdpPIj3T3DdaMwaebjxzqLt+4yIyl4P0CiEcAtyfklX9MeAOu5LdH5p6dzc9yufHsh7U9CUxUlp9F+JqpgZzKp6X7IEOpDTqpCe0j/QzvsX5WE0tYU8M1qM3XFWtJ6JPpQ1h2F0BQvZh8t1v0YAx+IQqEgCwuvDjOjKESjQTgbR4rm9aqTeEn5MFw43JNFt/Sz72o7xADsofuK2juYW3P8QzaGYJjdqmoXswfPg3mgtbPWvLYWzk/3iudzyASMA== 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 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