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 40B12C001E0 for ; Thu, 27 Jul 2023 11:31:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8F3426B0074; Thu, 27 Jul 2023 07:31:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 87B916B0075; Thu, 27 Jul 2023 07:31:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F5676B007D; Thu, 27 Jul 2023 07:31:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 5B94E6B0074 for ; Thu, 27 Jul 2023 07:31:36 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1EED31404CE for ; Thu, 27 Jul 2023 11:31:36 +0000 (UTC) X-FDA: 81057176592.21.D05D968 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by imf14.hostedemail.com (Postfix) with ESMTP id 3AA2C100026 for ; Thu, 27 Jul 2023 11:31:31 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=Kgu7lcFf; dmarc=pass (policy=quarantine) header.from=collabora.com; spf=pass (imf14.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=1690457492; 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=/Sv0p192pOwoxkdwbAGwv7t6rgbD45OZwJxFUyZq/2I=; b=BIeMiMcwM5HYTNdwNw8ksxcSq5xp8a3C1PDvkkcO/xFfl4/5FxzXQfrsINHasAtT9ak+B5 SI/wT10lMvMfUCaz0x6PGHaibHf9SszJjoKo0Mle7zIz+iMp6kXPKW4ZP0lVOoD2OfMF+d Kkl/DuENxERRQ/wB6zix+EuUZYyV9ik= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=Kgu7lcFf; dmarc=pass (policy=quarantine) header.from=collabora.com; spf=pass (imf14.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=1690457492; a=rsa-sha256; cv=none; b=B7ps5kFSIJf4sfxvxRDiGG3BH7U6MUPlWy+Z4dcak+UlAuMm6Pbyo7koIewCJMWr0gMH6L QTp3v9bsFO1ppPvzT5wRvyXRf2cJKwAc+NAokO7EgTvfZ5KBXtWKngzA7xmvJAYJlTISTn IFjC87tj5fXObQNdmhQ15FIwwoy+hpc= Received: from [192.168.100.7] (unknown [59.103.218.24]) (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 95FF26607057; Thu, 27 Jul 2023 12:31:22 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1690457490; bh=QwGbrEQGGJI024TRKlZTazP2ydOrrqpiaW+jd0PA/0w=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=Kgu7lcFf3EpvlQmYW1IE3cyUf7qJnscHff1xjQoubuXKbU4ExNtRkW8Z8IHZDJqOs IXxru92rni9lSRWKvjObLgbWHUKMItwvi0xD5QSeHZPszFamTsoC4CNTYwU2mpx0B/ v28NqlvfD9ExtM+xDMnT0dbhwn29t/VQiujMYC2MI6BM6rifPilvU0HAiW2YKQJBUE 22SLiSUpW7dW0hwiw1a+niUbHy2W7Wlvx7k9HzaJY+q9S0ORwYH1U1AIxHV8KdCKiR BAxmXvTC/3WUHaYejcNER4w+b0xXgBo2BYfgOKoaqYubsKWC6kw4R49gcbkdHe7QYZ RI96tQJYcvr2w== Message-ID: Date: Thu, 27 Jul 2023 16:31:18 +0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: Muhammad Usama Anjum , "Kirill A. Shutemov" , =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= , Andrei Vagin , Danylo Mocherniuk , Alex Sierra , Alexander Viro , Andrew Morton , Axel Rasmussen , Christian Brauner , Cyrill Gorcunov , Dan Williams , David Hildenbrand , Greg KH , "Gustavo A . R . Silva" , "Liam R . Howlett" , Matthew Wilcox , Mike Rapoport , Nadav Amit , Pasha Tatashin , Paul Gofman , Peter Xu , Shuah Khan , Suren Baghdasaryan , Vlastimil Babka , Yang Shi , Yun Zhou , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, kernel@collabora.com Subject: Re: [v3] fs/proc/task_mmu: Implement IOCTL for efficient page table scanning Content-Language: en-US To: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= References: <20230713101415.108875-6-usama.anjum@collabora.com> <7eedf953-7cf6-c342-8fa8-b7626d69ab63@collabora.com> <382f4435-2088-08ce-20e9-bc1a15050861@collabora.com> <44eddc7d-fd68-1595-7e4f-e196abe37311@collabora.com> <1afedab8-5929-61e5-b0da-9c70dc01c254@collabora.com> <89c09085-19ab-462b-e3be-b4e492a85899@collabora.com> From: Muhammad Usama Anjum In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 3AA2C100026 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: a3jwk9ra8rifkdfnt1gkeoiuj6ke4u6w X-HE-Tag: 1690457491-577290 X-HE-Meta: U2FsdGVkX1/TDcHEARRWfna81pm4sSZoQjDIFCsWBouEE6st474HTBlrV7BZVNLp+3XN0fzOS3oIu2Pofg0xTrf2OM5sqsnVnpAQbcvFoyMVU7uaTO1exNlrSphqsmTMUN1hkTeqve3mQMwIXOY14y3Why97U96eYOAHWQ+LlRWLGNixCHImDC2cucJwo46B10j9+Ir3z5jDYav8yPld8EsCcoRxczjkzccsR5Ak8GL7eKxnDQB7IrB/irlmRq+dPpwYcG8nOjxxIdPko2rAKtKWKklhoKAGeSF2Nr3bL9EZX9XbyZqcGiPytlYJ3LhOzSPx1LKQGKfpfoAkYEtxSZUoLj1PMRR9C/B7d5e8QnxVMrOIyB69P48ezL4SbXKsxJDFlqffhhVponwHAp3B8BUEQIAdyRiLftX9hpFmyHRZ4b18erTwNF7KceUpDBCU17b/T0istk+9kKSEIMVlzH97D2eRKKxprdUOlWsd+gsly5bOQjTF38GhpzXYLiJGnwYvdtxwJ8ux5cvo9rLv2OVR8xOvMCpTDvcHJoz+yVEZmUKHypwY0NX217Cib64QjE8KdkKhT3aKTZRDdrkedFjD9XgCCLfw34p1ycXCw4/IU9d0DeGgEC0nAzxbKvxV4Z+R8CUuSI0mkXrbZNKFtMq1hQkJ/TmPTY5cLcgZqx+nRKxIdemngkhYMzzu2UCOoqZRFCKNhnicAme1vxxUlkb2FUiqCFvl+mYkPMDzTZvAtmNsHeVyoyrc3iKNH0YTzPVf2yVcvAWIcLAfuHl5a8p1zne+jUZjYSK04Lsfl2NXfO/OpXSv+czZyvWUBQ2StdYuljTvilHCTKpMuCZuvCm7Lu1OfktV78J6tC/XM4gaXboFMsE5spvNq6xXPQOb5WRIGPpw4Fb5+KxP1B0fmPVYfAUD8Tp3d+NrGYsXeg7vr7vDpWJgKbf5KulAdFpW/nc5YdK+kR+4YKjHyeu 9zerZgAU A32tSUs92WOHfBoDOeci+eQ3ycIHHn8wCvXz2MmA2wiZKsD0NeJn3Xz9CO82sEdoqucbCjHezNsTp7gTqe+j4DLpJ+nO09hVuCBBjXc2upE0p4dAlydPCQQrl3CDmywAGAHsl3hLyftMWF7s3kE6lPNEVq0AfyP3CK5/aXjBWO/9gYd0W5OFlcA6Jp97kkPHo9O+N5R+GF9W7FWrKuApDdC/9eYPtCTmTjKEZB44v6lDkrDccXhoqXN9xdOaK61135FhcPOgkhwUFXcSWjprz91nVSZQ1Qq3OqB1vrsj6pVYuvKabcbDANA/AcQB5KcKxxCWvKYa3a2hyXgb6mMG54ynTJH33j0tInxBte9KSCYT7aw0pe+inqnw0Vg== 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 7/27/23 4:26 PM, Michał Mirosław wrote: > On Thu, 27 Jul 2023 at 10:03, Muhammad Usama Anjum > wrote: >> On 7/27/23 2:10 AM, Michał Mirosław wrote: >>> On Wed, 26 Jul 2023 at 10:34, Muhammad Usama Anjum >>> wrote: >>>> On 7/25/23 11:05 PM, Michał Mirosław wrote: >>>>> On Tue, 25 Jul 2023 at 11:11, Muhammad Usama Anjum >>>>> wrote: > [...] >>>>> 2. For the address tagging part I'd prefer someone who knows how this >>>>> is used take a look. We're ignoring the tag (but clear it on return in >>>>> ->start) - so it doesn't matter for the ioctl() itself. >>>> I've added Kirill if he can give his thoughts about tagged memory. >>>> >>>> Right now we are removing the tags from all 3 pointers (start, end, vec) >>>> before using the pointers on kernel side. But we are overwriting and >>>> writing the walk ending address in start which user can read/use. >>>> >>>> I think we shouldn't over-write the start (and its tag) and instead return >>>> the ending walk address in new variable, walk_end. >>> >>> The overwrite of `start` is making the ioctl restart (continuation) >>> easier to handle. I prefer the current way, but it's not a strong >>> opinion. >> We shouldn't overwrite the start if we aren't gonna put the correct tag. So >> I've resorted to adding another variable `walk_end` to return the walk >> ending address. > > Yes. We have two options: > > 1. add new field and have the userspace check it and update start > itself to continue the scan, I've selected this option and sent v26 already: https://lore.kernel.org/all/20230727093637.1262110-1-usama.anjum@collabora.com > or: > 2. reconstruct the tag from either orignal `start` or `end` and have > the userspace re-set `start` if it wants to restart the scan instead > of continuing. In some case, compiler can put integrity checking metadata in the pointer's upper byte. So copying start or end's meta data would be wrong. > > (the second one, using `end`'s tag, might be the easiest for > userspace, as it can check `start` == `end` when deciding to continue > or restart). > > Best Regards > Michał Mirosław -- BR, Muhammad Usama Anjum