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 AD325EB64D9 for ; Mon, 19 Jun 2023 08:16:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 45BB18D0002; Mon, 19 Jun 2023 04:16:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 40BB58D0001; Mon, 19 Jun 2023 04:16:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2D3598D0002; Mon, 19 Jun 2023 04:16:18 -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 1F58E8D0001 for ; Mon, 19 Jun 2023 04:16:18 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id EB194140505 for ; Mon, 19 Jun 2023 08:16:17 +0000 (UTC) X-FDA: 80918789994.25.EE1EB94 Received: from mail-il1-f172.google.com (mail-il1-f172.google.com [209.85.166.172]) by imf05.hostedemail.com (Postfix) with ESMTP id 2AB78100018 for ; Mon, 19 Jun 2023 08:16:14 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=6jB0Vaks; spf=pass (imf05.hostedemail.com: domain of emmir@google.com designates 209.85.166.172 as permitted sender) smtp.mailfrom=emmir@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687162575; 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=nUxNLC+gaxAx6q4yk9Zr89shiO34QlAjv1HZ696Wg1U=; b=xPz0J3dYgzGrGcHkiXkFooOfho6CPLxsDGKhZwep98aIkWmoRiuG02TeDV4mfd+iAVB6YR +w2qt/5hGoRhgJcNE2S3rnJTKXu4FIfwiza4nIrpKA/f8eLUOkGoeqYZlq3dpVn4eB/y5i Z0izjHWRCiO7eea9Fk4HCnRhDKHNHGU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687162575; a=rsa-sha256; cv=none; b=v4cG96Nydk+be+YiKoAglDgetuGRrKYyAA3un0PgENVpR07mlZki4Yw8nC9GB5SKEN5f1r 5gB9KrsP6byWGoCyVEAx1nV9oIVHsI9N7nE2m0DQMDjlomxtR345P7RrUzWlAIkN5CJxY9 4EAWqScuihLrlB+cUGPidoD9deJnrgE= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=6jB0Vaks; spf=pass (imf05.hostedemail.com: domain of emmir@google.com designates 209.85.166.172 as permitted sender) smtp.mailfrom=emmir@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-il1-f172.google.com with SMTP id e9e14a558f8ab-33d928a268eso279245ab.0 for ; Mon, 19 Jun 2023 01:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1687162574; x=1689754574; 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=nUxNLC+gaxAx6q4yk9Zr89shiO34QlAjv1HZ696Wg1U=; b=6jB0Vaksw7QYyR3aieZrQMpKBSoFdhf1SglIAWLr1IUfcUcsjNjZT047OxQ/zQDxn/ Q9VLzY0piRJkaAmLa8H4wzNvh8yfWhfZ2IWwJ+gHskDnk2EqS3ffbkHr01hFU11k/zF0 xgsVP5PPjtZeLsInnU48wBXWitsB5Cg42pRR7NSKqCaGZsK8UpHqajQTimFQ0q5vd/9r acH2E9d4CQJy/awvToQdq8wrpNqwUmb65hWO8yhrGnfXzNPlCCI+qzY7RPDt1S85CFV0 QZ8a7hay4Wk37tQGl8s76uSpDIge/MKmH10WPIqNLvcYLXmP9kohSEeLvCiG8udvDi4l XIRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687162574; x=1689754574; 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=nUxNLC+gaxAx6q4yk9Zr89shiO34QlAjv1HZ696Wg1U=; b=EnCIadi33t1+7sNAphl8M9qWbQczWb2KgK9zmKE2UBD8gaeP5ztwCQdrSVG+slXoY9 TuudIHWJv7YSczajmaAWsq2R3xn9mYb526QJAZHnolYK5wDCtX1/xbOZScHRZIkR6VQm yIY0u5+MaJIET5vKHASp+vK9qye76ODWdOAGK9JK5n+8J4Mcd9PbzjfPNAoVJwOvAQb7 VvsglZGU1DtoihVj15hJQMP1vKZCQBltC0HauUU7dq5OLI5Krc0oTLtJeIn3V+m5dymb dryKfy43+YngvdiYYX5ZL+fQZIGPSivg9KTsoPP3N9OcvHoU94qCPybQIVyQckVMksK0 OxeQ== X-Gm-Message-State: AC+VfDzACgI2KvLTrK5T24wRVP1slMZ564Y2+CYV5jABEdO3U/ZTDc3v aFIfVwaR097vJnmdrXen0+lyxiXYJb8jb37/QIYJtg== X-Google-Smtp-Source: ACHHUZ7pPgmfxfjpyVDu/lfSWd41l6pU01tdM9sEKUPUeywUHyKDUU+RDI/ym0egdMQruqWyQjzGX8yWcNRZAY/X9kE= X-Received: by 2002:a92:c243:0:b0:340:f76:4292 with SMTP id k3-20020a92c243000000b003400f764292mr894272ilo.0.1687162574121; Mon, 19 Jun 2023 01:16:14 -0700 (PDT) MIME-Version: 1.0 References: <20230613102905.2808371-1-usama.anjum@collabora.com> <20230613102905.2808371-3-usama.anjum@collabora.com> <0db01d90-09d6-08a4-bbb8-70670d3baa94@collabora.com> <34203acf-7270-7ade-a60e-ae0f729dcf70@collabora.com> <96b7cc00-d213-ad7d-1b48-b27f75b04d22@collabora.com> <39bc8212-9ee8-dbc1-d468-f6be438b683b@collabora.com> <2e1b80f1-0385-0674-ae5f-9703a6ef975d@collabora.com> In-Reply-To: <2e1b80f1-0385-0674-ae5f-9703a6ef975d@collabora.com> From: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= Date: Mon, 19 Jun 2023 10:16:01 +0200 Message-ID: Subject: Re: [PATCH v18 2/5] fs/proc/task_mmu: Implement IOCTL to get and optionally clear info about PTEs To: Muhammad Usama Anjum Cc: 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 2AB78100018 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: rzyfwu5rbbq1m64t6iu76z6fed9j3jce X-HE-Tag: 1687162574-819659 X-HE-Meta: U2FsdGVkX18K3fjEtwgm2CK7MqYax8YOQXfStlTMYjiJWaWcqtShVb9KEhlo59n+mYG5qcPOAlVe8+U5j8xIG7Gch4eUxx+ms91QWZRBVKeAXFwq2+FM6MdJJvMihhwwt9MjdOjRDu/gHramPM87OHRL1R9zcdZUyMMFdpOIIgxCkhvSmjBe8Hcm2u2OfrJ2xgX8Gn/oBd1+QRi/zY9XJUoDHfwN9ES6IRWZmQaoOYlOFJaC70eoKMt7M33sSoPuvqEgkcBOduwgrE9zNRx23CDy4R2KHqH15OEojqfpstDBXGzAPMIagsBTmFIsIlqWxKYR83bDUn9TPBoJgNjUoFlDvkkuNI2dkofn56SJx4kiOoeKWtjwZp5+ZB4IYCfXWSgdvb4PrGqk3ify+qTURvqGUA5KMnZ+GxPUQDSOUsbPpbtmh3/Fdpl3Fjo9Xb+oQrkKS5GQpSippWO6bT36mvwl3R/u+t3OuB+054hNiaV7L2LjW9lZPIm8idsW4sh8s6iaKK8llaZiQ/gfmIRY8eHJYXiF1V3YFcKqQVN04uN07M1wGv8tMINBO43mwgXa75PRS/yop+mfrsSG0CoGbT+h2CLecoPnyDxMkqRolNNk7GDEeBm9SzzHsDUmEY7QZClG9S524gJrrO2fMIe+Z/xg0OX8Iy8+uzo6GL6o4YbEYctbgeIZR/Kig7cTmyoHMDUqVbIA5HE/0IaZAWjZnaklfRZHZcbVKxL4dLkN4pQDJNQErVhwVXo9egB0PQACbZh97tMffeeZRFbyGfbDfaENfbgEsKEljnYyAauWnceRNASJeopd8Oc75PFJbvj0MR81pFoQRwAv1ocacYPHn0BcuMA//+Ugg/mIZaUm7nZ6xCKfTqMxtHaPl34HOOXnqKLLeGia33t2NrimfIH/lruYpS9yJh/U+AEtMqpOI5asjpcDk2DRyKiI6nhaXhTEY6xyUHbaDf3jxljNVAN Do5AMESw yfY17BGz7c56R/OMJ0aLARgcgqK00GForApHvOMvaDdAextxqNzjTc3cvSgzR5exYYEg3ddT2wNosbrcKXOWhoPbx9Yeaq1jVN5fIyEz9C7aSs0F3ncKPIeRxcBOnjBNHNHiv6Y30c92aeMjm13Np7q0n2VIupq9FBbzkTYcd/d9cUPTvlToG9DOnh3w62KnPdQMXE72jXvKfHtTGXyL7avUmfsYIxtr5t8OQHkD/5WG3oaE4pcdmF4Gas4Rpd2koJi1+Wz/ec0kz9b650cNdan5K2t0N2qsUT1fZNr0jhnDUdl6upOnvvSKtHbVE/60N5WKfOAtojoxR9LriW8ncj2m/6c6vmSoEvP1QiXfQ+I2R3DW8LOuDOw1xea7W8Ybn6Z7a2pqJN7RSYpHsLc6ixHuYfKAsS+MwQCN4TwRWY9hQwhL/kadNzCKqTvvXMDYvGVxT 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, 16 Jun 2023 at 08:57, Muhammad Usama Anjum wrote: > > On 6/16/23 1:07=E2=80=AFAM, Micha=C5=82 Miros=C5=82aw wrote: > > On Thu, 15 Jun 2023 at 17:11, Muhammad Usama Anjum > > wrote: > >> On 6/15/23 7:52=E2=80=AFPM, Micha=C5=82 Miros=C5=82aw wrote: > >>> On Thu, 15 Jun 2023 at 15:58, Muhammad Usama Anjum > >>> wrote: > >>>> I'll send next revision now. > >>>> On 6/14/23 11:00=E2=80=AFPM, Micha=C5=82 Miros=C5=82aw wrote: > >>>>> (A quick reply to answer open questions in case they help the next = version.) [...] > >>>>> I guess this will be reworked anyway, but I'd prefer this didn't ne= ed > >>>>> custom errors etc. If we agree to decoupling the selection and GET > >>>>> output, it could be: > >>>>> > >>>>> bool is_interesting_page(p, flags); // this one does the > >>>>> required/anyof/excluded match > >>>>> size_t output_range(p, start, len, flags); // this one fills the > >>>>> output vector and returns how many pages were fit > >>>>> > >>>>> In this setup, `is_interesting_page() && (n_out =3D output_range())= < > >>>>> n_pages` means this is the final range, no more will fit. And if > >>>>> `n_out =3D=3D 0` then no pages fit and no WP is needed (no other sp= ecial > >>>>> cases). > >>>> Right now, pagemap_scan_output() performs the work of both of these = two > >>>> functions. The part can be broken into is_interesting_pages() and we= can > >>>> leave the remaining part as it is. > >>>> > >>>> Saying that n_out < n_pages tells us the buffer is full covers one c= ase. > >>>> But there is case of maximum pages have been found and walk needs to= be > >>>> aborted. > >>> > >>> This case is exactly what `n_out < n_pages` will cover (if scan_outpu= t > >>> uses max_pages properly to limit n_out). > >>> Isn't it that when the buffer is full we want to abort the scan alway= s > >>> (with WP if `n_out > 0`)? > >> Wouldn't it be duplication of condition if buffer is full inside > >> pagemap_scan_output() and just outside it. Inside pagemap_scan_output(= ) we > >> check if we have space before putting data inside it. I'm using this s= ame > >> condition to indicate that buffer is full. > > > > I'm not sure what do you mean? The buffer-full conditions would be > > checked in ..scan_output() and communicated to the caller by returning > > N less than `n_pages` passed in. This is exactly how e.g. read() > > works: if you get less than requested you've hit the end of the file. > > If the file happens to have size that is equal to the provided buffer > > length, the next read() will return 0. > Right now we have: > > pagemap_scan_output(): > if (p->vec_buf_index >=3D p->vec_buf_len) > return PM_SCAN_BUFFER_FULL; > if (p->found_pages =3D=3D p->max_pages) > return PM_SCAN_FOUND_MAX_PAGES; Why do you need to differentiate between those cases? > pagemap_scan_pmd_entry(): > ret =3D pagemap_scan_output(bitmap, p, start, n_pages); > if (ret >=3D 0) // success > make_UFFD_WP and flush > else > buffer_error > > You are asking me to do: > > pagemap_scan_output(): > if (p->vec_buf_index >=3D p->vec_buf_len) > return 0; > if (p->found_pages =3D=3D p->max_pages) > return PM_SCAN_FOUND_MAX_PAGES; This should be instead: n_pages =3D min(p->max_pags - p_found_pages, n_pages) ... return n_pages; > pagemap_scan_pmd_entry(): > ret =3D pagemap_scan_output(bitmap, p, start, n_pages); > if (ret > 0) // success > make_UFFD_WP and flush > else if (ret =3D=3D 0) // buffer full > return PM_SCAN_BUFFER_FULL; > else //other errors > buffer_error And this would be: if (ret > 0 && WP) WP + flush if (ret < n_pages) return -ENOSPC; > So you are asking me to go from consie code to write more lines of code. = I > would write more lines without any issue if it improves readability and > logical sense. But I don't see here any benefit. Please see the clarifications above. Best Regards Micha=C5=82 Miros=C5=82aw