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 95CF5C001DD for ; Tue, 27 Jun 2023 18:52:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231217AbjF0Swp (ORCPT ); Tue, 27 Jun 2023 14:52:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37200 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231202AbjF0Swo (ORCPT ); Tue, 27 Jun 2023 14:52:44 -0400 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 359E919A8 for ; Tue, 27 Jun 2023 11:52:43 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-51db8a4dc60so1314a12.1 for ; Tue, 27 Jun 2023 11:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1687891961; x=1690483961; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=zrMUD+bzjYq5U/OlRQ46C95vvZ+AhNRjqJFLfHa8n58=; b=Lwjol0KzgSFyHrtVjCTTjkFPYma+RQF77JRbL0wBs9NJOySx0p1L2f3KoQOq2wtYew bTbS4LUyDDLndkY34CBSLWvRzEdphSFvMUqTZGeF54WZZxThj2qDyI+xzBCFM4pogR7W 6bazPitMsZvcEA2YauBwiyijlOt2eO2AU6tgt0np1VbzJ0e1mNjUm9eEqWYW+z1kIExA Z01Z8niT6EkjqiZzq1atZgnkgvSbxGXUcTwbQbaWqN4xOUMT4xyf3shnyJrljigB3h2A KL/F/itIeavYuh/huelf/SLkHAf8a+Z3lf6f75s5Rw9smZoquAjZxv8gONeapQ66QuF+ fv8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687891961; x=1690483961; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=zrMUD+bzjYq5U/OlRQ46C95vvZ+AhNRjqJFLfHa8n58=; b=PKTG3gU/MPIXYZBAlqgTJ9Ukfs6uaAg3UbS0OLkez1BWU1mNG74BfIzbYp+b092JJj ZWAR9CfYvCBuY1YsNSiPKh3kKioq5rLmJD7PMVCd3ZOlC0FsrEGpSEj0vfuckiTRnPys H4ZoIBadSj752jVgMz5Ys/bnCtKOSqbjdvaEy/0zEAz3yrtgM/Pyrn+SGm47PEI4CcKN huHvoUPbtvqAQTHgAY2AazusB2d4p1bV9GCEJKvqDKfX6lOTZpD0YHID4cVVhTDMdhYz chFM50vGKs1qswfolpzfE1ksWt5atchbfaDOkrGGSoX3PRTMzmO8Dq7qai/PMyU9IFE8 q4zw== X-Gm-Message-State: AC+VfDwaMoQ9vfTBu9g1WFcHmqmvQLyT8znlpT3FKUYkjyUupK2gdaZz tDzgDL8996sCycdlaF44Q3LTNlipatjmm48ZPY7KcA== X-Google-Smtp-Source: ACHHUZ4NqtygUkoF7LzNQuMwk4m82VidiZ4IS+yy+S4o+fhpUQ0AL4Z3k4FCruDAhBmmEv8MVBz6pucYVp9kK7qXtpc= X-Received: by 2002:a50:a6c3:0:b0:506:90c4:b63b with SMTP id f3-20020a50a6c3000000b0050690c4b63bmr12556edc.4.1687891961572; Tue, 27 Jun 2023 11:52:41 -0700 (PDT) MIME-Version: 1.0 References: <20230626113156.1274521-1-usama.anjum@collabora.com> <20230626113156.1274521-3-usama.anjum@collabora.com> <13ea54c0-25a3-285c-f47e-d6da11c91795@collabora.com> In-Reply-To: <13ea54c0-25a3-285c-f47e-d6da11c91795@collabora.com> From: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= Date: Tue, 27 Jun 2023 20:52:30 +0200 Message-ID: Subject: Re: [PATCH v21 2/5] fs/proc/task_mmu: Implement IOCTL to get and optionally clear info about PTEs To: Muhammad Usama Anjum Cc: Andrei Vagin , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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=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 addre= ss? > > 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. 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). Best Regards Micha=C5=82 Miros=C5=82aw