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 BCD7EC0015E for ; Sat, 12 Aug 2023 14:22:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C04DD6B0075; Sat, 12 Aug 2023 10:22:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BB5036B0078; Sat, 12 Aug 2023 10:22:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA3D06B007B; Sat, 12 Aug 2023 10:22:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9C3E56B0075 for ; Sat, 12 Aug 2023 10:22:21 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 4DB7F1C9480 for ; Sat, 12 Aug 2023 14:22:21 +0000 (UTC) X-FDA: 81115667682.02.D66FBB2 Received: from rere.qmqm.pl (rere.qmqm.pl [91.227.64.183]) by imf13.hostedemail.com (Postfix) with ESMTP id DB9A42002E for ; Sat, 12 Aug 2023 14:22:18 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=rere.qmqm.pl header.s=1 header.b=c3QN0Pdb; dmarc=pass (policy=reject) header.from=rere.qmqm.pl; spf=pass (imf13.hostedemail.com: domain of mirq-linux@rere.qmqm.pl designates 91.227.64.183 as permitted sender) smtp.mailfrom=mirq-linux@rere.qmqm.pl ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691850139; 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=n4OBDHZhaecYk2HQNt9EqUoSLTkltaLUc4mc2oRO//Q=; b=8nJJUAAmN65M1Fwjl3Se9UL+ZtwR6TYxif1+ZpGZODnS3dXIIi5a03pk1kVahUDO1G3haX XyvDzra1xiwfyN4x4+VqZQED2b5myocwftVe8m8p8twtwZukKcgMfon4dESf65O61EaLJP 9Yu8baVTxV6FYDhBxi4KYLa9s4EBGgY= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=rere.qmqm.pl header.s=1 header.b=c3QN0Pdb; dmarc=pass (policy=reject) header.from=rere.qmqm.pl; spf=pass (imf13.hostedemail.com: domain of mirq-linux@rere.qmqm.pl designates 91.227.64.183 as permitted sender) smtp.mailfrom=mirq-linux@rere.qmqm.pl ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691850139; a=rsa-sha256; cv=none; b=imtPo6+svPu43rSpkgpgxjESvt2I/pPskE+AY+LSnwF/g8DUn/QrQ7BAnHC8r2kmMaqDVw +7w6hLL1EhYxqlyGEYcZnia8b3+XGwos729UcX0euZt7KUjyqdAK/M7sxzBqisqCXDfbTz anoadYGp++4bTHyhSH456GTkSzGonIg= Received: from remote.user (localhost [127.0.0.1]) by rere.qmqm.pl (Postfix) with ESMTPSA id 4RNNCR1K35z8L; Sat, 12 Aug 2023 16:22:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rere.qmqm.pl; s=1; t=1691850136; bh=u5bq7pd5Cv90/Zbgy2FhjyRSbq0SeJ3nBFKvllWi1eg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=c3QN0PdbGboHQRbBeobFKVXGXglpVS0Mrl0gqCrK49+VoIjGt/OyVtf9lbfoSz5W7 oXedUXsCMS59O0kX2vamz4MNt1flWx1AorUMh2Cc+gp7Gn/pbvaHsHb/n4JSDv1pfg v1By/PS1eu61cqPVOE3EtQ53iHf7pELje3zmG5My2sG/sjaL8GmlADrKRr0ANFf+JA hij/Eo1vOvA/gzdJR9QUOLskfTfw6WD77N1V+1DgRzPpsy3u/BDqGtlLsXT/tnRPHC MkPyYl5LxLUVuFu/NF/42rz04gFxscyMb6I63fmubnrp5lGQ4szPSjD2yxXnivZ69i AvvZCuk7olxxg== X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.8 at mail Date: Sat, 12 Aug 2023 16:22:09 +0200 From: =?iso-8859-2?Q?Micha=B3_Miros=B3aw?= To: Muhammad Usama Anjum Cc: =?iso-8859-2?Q?Micha=B3_Miros=B3aw?= , Peter Xu , David Hildenbrand , Andrew Morton , Andrei Vagin , 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 v28 2/6] fs/proc/task_mmu: Implement IOCTL to get and optionally clear info about PTEs Message-ID: References: <20230809061603.1969154-1-usama.anjum@collabora.com> <20230809061603.1969154-3-usama.anjum@collabora.com> <97de19a3-bba2-9260-7741-cd5b6f4581e9@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: DB9A42002E X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: kykhj9ki63tsj9r5fhzfi5ex88j8nzmx X-HE-Tag: 1691850138-998605 X-HE-Meta: U2FsdGVkX1/fGJwDsunVuI9Qp/3wZ45SPyzSpdEgmdAhHaJIDtaTDXxYVaWYtYrGe52IZkJny6VsHdOq+HLX5ssJgpwtfiNNIL/enH8XfRHiGnHGY+RTkrmG3wlaUHXisqoUtTyfgjZjbPJwGvDKn/G5IPnHVnCKxohlZ1SQjcciGvcELNYE6cs7T3sPxDQO1y7dsZmYAk9lHc0RJKxxifB4lwyQYxH+fmjidovOOSajYK92c4ZOMNVRq98k/8rJ/Pv+lWyXEpDeIfa2NiMU3871iuLz6A0cQvmrWGDCuylLYOlFSUbWs1l5XHXnuz3MAUr0NcZivtbVbe+tReK4IHEdUdnYsHGZV+gUv/bPaE65RAvA1KugHbitTG9AJoaQGTbXLkJlMGbrqHPOwn7OYV6MaafvdoYgR1ZH1zUwz9tbc1H0dD+X4PCcC7vR1aVzRC2/rCs0MIlVEDMKwGsUSnZnVwYCciRUVahtjUxy9X8ZXcGtb8CzWqUtrvwClVHw10Nr/+zUDihyMdirqzuJeOWYilsvPZqTz5T2H4pXnmqimx8XQUUhQyj9Jage/rM6UtxEI+6AKmJwza4fgygXSHuLUoTM4pl+J4pOLNwx6K0IyM9qAqd5bu9sDEmW8kQLogMFw1x0RYuCehE3Q9JOU3JcxpJN5/uN8k/K1oJgoK5meXlhRyy996GsUkaJVm4Z7Gw5OuW//9Rm0y8LUy1NsDAAv5uTcmJXdRoOK3N+PvVDTes4/hhQtCPuBIF/LqHwt0YCCsC7KbCis1Nfq02nR6fDGzwBTxx5Qdla/lbkbRHBJ/JdDxhFRWXYXXDqcuUMDZ++W6Y/SyhXDRYEztFmRq0/9h8yixOMzHIlckkD4EOXdA9UZvxXG6HiVlT4ugcHDodTNYZcowI0JvYqaMHmfoyetIw4SbR28kLm7ZaBZoDxAE/MVKBkawvultBGRI8NmhsSFR1srB+B4M06g+q ioKz2Orv 0zuDt2aCKZTaP4kgnOnmw4f0aRmAVtBUhy9/ZDMD3eoajTtzuOKfFQPSUFsAICtjVi7A+XtQDoByd+ds0FfArRcVHhpHFaK0C3GtfCUxnqrAw6/1e74+50XuWbUqUXuoWXzKXs3HL48wvv3UxNFO8tsxMtp/BaO6P9UMvRMTGWWEk/Y23MBr+2/hcUglQ1W/YbT1YJaJLx8GXVxLcWPdNxSy9sidG2F+cx/PymxL/omVOydjcYOiiHyFfgQ== 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 Fri, Aug 11, 2023 at 08:30:16PM +0500, Muhammad Usama Anjum wrote: > On 8/11/23 6:32 PM, Michał Mirosław wrote: > > On Fri, Aug 11, 2023 at 05:02:44PM +0500, Muhammad Usama Anjum wrote: > >> Now we are walking the entire range walk_page_range(). We don't break loop > >> when we get -ENOSPC as this error may only mean that the temporary buffer > >> is full. So we need check if max pages have been found or output buffer is > >> full or ret is 0 or any other error. When p.arg.vec_len = 1 is end > >> condition as the last entry is in cur. As we have walked over the entire > >> range, cur must be full after which the walk returned. > >> > >> So current condition is necessary. I've double checked it. I'll change it > >> to `p.arg.vec_len == 1`. > > If we have walked the whole range, then the loop will end anyway due to > > `walk_start < walk_end` not held in the `for()`'s condition. > Sorry, for not explaining to-the-point. > Why would we walk the entire range when we should recognize that the output > buffer is full and break the loop? > > I've test cases written for this case. If I remove `p.arg.vec_len == 1` > check, there is infinite loop for walking. So we are doing correct thing here. It seems there is a bug somewhere then. I'll take a look at v29. > > [...] > >>>> +/* > >>>> + * struct pm_scan_arg - Pagemap ioctl argument > >>>> + * @size: Size of the structure > >>>> + * @flags: Flags for the IOCTL > >>>> + * @start: Starting address of the region > >>>> + * @end: Ending address of the region > >>>> + * @walk_end Address where the scan stopped (written by kernel). > >>>> + * walk_end == end informs that the scan completed on entire range. > >>> > >>> Can we ensure this holds also for the tagged pointers? > >> No, we cannot. > > So this need explanation in the comment here. (Though I'd still like to > > know how the address tags are supposed to be used from someone that > > knows them.) > I've looked at some documentations (presentations/talks) about tags. Tags > is more like userspace feature. Kernel should just ignore them for our use > case. I'll add comment. Kernel does ignore them when reading, but what about returning a tagged pointer? How that should work? In case of `walk_end` we can safely copy the tag from `end` or `start` when we return exactly on of those. But what about other addresses? When fed back as `start` any tag will work, so the question is only what to do with pointers in the middle? We can clear those of course - this should be mentioned in the doc - so userspace always gets a predictable value (note: 'predictable' does not require treating `start` and `end` the same way as addresses between them, just that what happens is well defined). (I think making `walk_end` == `end` work regardless of pointer tagging will make userspace happier, but I guess doc will also make it workable. And I'm repeating myself. ;-) Best Regards Michał Mirosław