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 3925EC64EC7 for ; Sat, 25 Feb 2023 09:39:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 607756B0071; Sat, 25 Feb 2023 04:39:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 58FB66B0073; Sat, 25 Feb 2023 04:39:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 409506B0074; Sat, 25 Feb 2023 04:39:11 -0500 (EST) 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 2C88A6B0071 for ; Sat, 25 Feb 2023 04:39:11 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id EF9211C65EA for ; Sat, 25 Feb 2023 09:39:10 +0000 (UTC) X-FDA: 80505315660.12.AD52813 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by imf23.hostedemail.com (Postfix) with ESMTP id 37BAA140003 for ; Sat, 25 Feb 2023 09:39:07 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=smswoQUu; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of emmir@google.com designates 209.85.208.44 as permitted sender) smtp.mailfrom=emmir@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677317948; 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=iEX7kiTnmPMmcWsePbfgzYz4jb8Fx2x4hoDMfgu0V80=; b=ECmTWnd8uuvJk9EyK/fJL3gkXyQnEmO7Ld9etivz5JuyWVD6QA2RBH/azG9S7+vxnOlTxE Ao6AaqSdsHpPCoeAXMSaKEHGwBKypn4A4niuJOxfDBrV0AuwlxgZzZ6pcZude/h/x4Nn/T 6P1/zwPGOI/MEzWqs6F7727pTAM+38E= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=smswoQUu; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of emmir@google.com designates 209.85.208.44 as permitted sender) smtp.mailfrom=emmir@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677317948; a=rsa-sha256; cv=none; b=3ipkMGnrpmj70w6LUXdY0Osh13IFQXq9QEIq8fZQKKdb5Sp/vS+0rlXSq25OkiDjqqhD/3 cxLHGavm9zWhq6Ld47I25OgiPEsizWOA6s3rtQ3Bok4WLGFo8nnhzEStiLvseWozibEWdi Q86EFALpBz9dh0fzZc3gvI5VOOD29fc= Received: by mail-ed1-f44.google.com with SMTP id o15so4221029edr.13 for ; Sat, 25 Feb 2023 01:39:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=iEX7kiTnmPMmcWsePbfgzYz4jb8Fx2x4hoDMfgu0V80=; b=smswoQUuwUF4XY9LDbRmqUcx0OKWdA9ePrsQVB6KU0TUncGg/HFOeZDRQErPWVcnwC h33FfHaRo1bvBUNLyOaHEkiISPvZCFGdE+YPAFJKlf9gpOcF3c3xY7sQ4Y4sLC7qYcul xYWi9SgSdtEmaRxZXpCf10qZwUqKvIaZ6QPuRLGvl44yTkjVD0pIvtQuD0pCueE4I4QI qwlJ/gFdDY1bzMXein1Qp5Q6d9mwOSHYczuRNGGRAAvKfSZNppbnsOVDu8wyra4Lw5Td 4pldOG3htUTw94jldyivuKgDTeyITzvKNRnYLEYI2YZsa18GqUafsAT9O5zpo6ZzD7Vf B14w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=iEX7kiTnmPMmcWsePbfgzYz4jb8Fx2x4hoDMfgu0V80=; b=BBwTrpPENO2UriU0fqDKTG67AxeNOs+f5iJThLLiOxXu0VsquDGs21mff7YRAvDtTo S8lQR9u/ey0v8Rc5gVpDWWLm+t+IOt7LvROYyLNTX3jivWzMplzG3RaffF7L9/3K6eXx D/dE+OG+QPLJc+X9eSuLdos9C1vtW5M/bIR7JFc3TwCRsN7VlvJo2jR7WOQn9QrwqaRi z4bCPj5VilfeuxEsreV6rJMJ0+eUor+Xly3MqviAqIxUzO1VkD1TUUtYVecKcEIzNp/9 Jh+0tpyv2jZZeKQe6K27RDRKw5/cIhfcfdjigtGmk6MKlUFl3o2oACSoH2VLFqI/NftL Eesw== X-Gm-Message-State: AO0yUKWONofKwHUM6sgd/ii2d0RSuJvI2ETpxKgUp/n+1JyxfZsaBqqV GGvvV20XiifCba2D1ulm1n068Nv5aWHZA4sNpyuHeg== X-Google-Smtp-Source: AK7set++MnoeXQd72vVgpXhRE0kCu5mb/bg06wZYyCPMNKgIUS3bvXglSOQnhR3IZsU/EjQNxWWXsYJhvb6B+BVpJHI= X-Received: by 2002:a17:907:2ce6:b0:8df:dc64:30d2 with SMTP id hz6-20020a1709072ce600b008dfdc6430d2mr1821694ejc.1.1677317946487; Sat, 25 Feb 2023 01:39:06 -0800 (PST) MIME-Version: 1.0 References: <20230202112915.867409-1-usama.anjum@collabora.com> <20230202112915.867409-4-usama.anjum@collabora.com> <36ddfd75-5c58-197b-16c9-9f819099ea6d@collabora.com> In-Reply-To: From: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= Date: Sat, 25 Feb 2023 10:38:54 +0100 Message-ID: Subject: Re: [PATCH v10 3/6] fs/proc/task_mmu: Implement IOCTL to get and/or the clear info about PTEs To: Andrei Vagin Cc: Muhammad Usama Anjum , Mike Rapoport , Nadav Amit , David Hildenbrand , Andrew Morton , Paul Gofman , Cyrill Gorcunov , Alexander Viro , Shuah Khan , Christian Brauner , Yang Shi , Vlastimil Babka , "Liam R . Howlett" , Yun Zhou , Suren Baghdasaryan , Alex Sierra , Peter Xu , 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, Danylo Mocherniuk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 37BAA140003 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: u3yp4ugbh765js96dejwww19r8tfmhrd X-HE-Tag: 1677317947-34659 X-HE-Meta: U2FsdGVkX18m9Mf83LH5UBMZVYU5jQQQLPexdFHD0v1fRS1d0T09F6kly7bW29zJBsDL7+1zeU8PIo+pmo4qB6T7uRkzEinGoK558YT3+1btwqTR+7je4J4LE/iJYcrC3ESuF9gfgZ+uY2KqKlTRTVKSsbenAwanOwHFyKkzVFQl+iHr9TUHi3/nzhOXe/dEdjyXRGY/AAEtb2Ub6dJerRY09VoJ8QUHKPu5Gl6c7BLN59S9FHZWpI1z8oS4qO/jOVovw+0/ZMFpHkDFFb8/Yz5nJIc2PLt4FeIWbdV0cydMfq5nmu1wcXkBibxeXdBqYH0MvdeOOswfToxDFYPKRKFjb6b2T76TPNnRGClW7iZXdO6sXVyzy9TaKrogM8+b/aoRi59qSV5UxS4GS6612IryAZQdtfULQaIztD7/jdzoq5Iv2FGFaTjiYqtJfjs5Jysw6HnJej++I2/GziiSGzOsacNPRRzITlfcxr6Zq7I19qd4m2HvBTEwakC89Z/XkGTCZboxYVLrvuRL1eYs0Es7M6nzRBYaicDV78Ypy1XfQNkKTmatCA66eSz2zIUL42vm/a73+qOSMydMsnos08MQpfT65zlWFOP0W5eWjW6DFSxTZfq3JWakWlOmITtAyxQwPI7EOvvwgvUdQixgQAScAJ0ocM6EndDTJlDu3lTxC9M4+08iif0jq9aTcE/5aKi300v3B6+dAhIJuuBffW/m2be2sFl6mAxXo4AEkTZUHXB4pCGiJI8p89LWUx4fXGhPEvJLPpkTG4DEH95770ay4jHl9nkXcFlPRcnffPF93WDZO5Yf1m8rQlKdBdZgL/cdhs9BR8cJqkgZ3IDps3QFNoMsegyOgbWDvo5Wp0HM9SD3aRCgHJF0kheJ19q/AN6dnvOqSw+c/dXJDQGsQM9JZT/c+6ycWv7lXKwtg52kH2q5zcRl4V5Tth6Lxzd/3KOJZTdKoMW/DuSI7KT tdKGU6Pe mfWzrRTjRG7wKBORLqWzBiOto+2fajr5SdN/6awyWh0M5UJRr2H1fPhNYTYhfFprIQFw5xhGRy4bIkBI1KOX+QR9QAFifeHV/7xKT0T6SoUbT5+Mokf7UkCqPLFGsBaVrqZDYbUc4iR0IEwD4QRAJ2oZS1TLt2Sdc91q+k+tXD+mP8Gg6aeo0PY3s8BBEMGr9xNvwl2fcSZGFS90AYOKZa7ug0uKAB/1Qr9cabPOMBJ7ETst8pTagUU98e+wzea5e2dSoPt2FpgmIgG/NQJIK9bl/KA7oBwnquHyjWKJ8XwqGJ9Wa3ZWoQQUmTn5sa/nuSf68n0F1dzgPOvzEP2umEtc0g9tk1J/rMv4MRw8LK/QsFMfP7hLgqv1xFsWiEzlGwylfXBZjKrsi63kv1/SlJNXNseVH5kVz2WAvjDAg4gPqOZbjtquhH22XjuIIU6F0k6I1erWkJuiTYLe7KJtWJ0wClg== 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, 24 Feb 2023 at 03:20, Andrei Vagin wrote: > > On Tue, Feb 21, 2023 at 4:42=E2=80=AFAM Micha=C5=82 Miros=C5=82aw wrote: > > > > On Tue, 21 Feb 2023 at 11:28, Muhammad Usama Anjum > > wrote: > > > > > > Hi Micha=C5=82, > > > > > > Thank you so much for comment! > > > > > > On 2/17/23 8:18=E2=80=AFPM, Micha=C5=82 Miros=C5=82aw wrote: > > [...] > > > > For the page-selection mechanism, currently required_mask and > > > > excluded_mask have conflicting > > > They are opposite of each other: > > > All the set bits in required_mask must be set for the page to be sele= cted. > > > All the set bits in excluded_mask must _not_ be set for the page to b= e > > > selected. > > > > > > > responsibilities. I suggest to rework that to: > > > > 1. negated_flags: page flags which are to be negated before applyin= g > > > > the page selection using following masks; > > > Sorry I'm unable to understand the negation (which is XOR?). Lets loo= k at > > > the truth table: > > > Page Flag negated_flags > > > 0 0 0 > > > 0 1 1 > > > 1 0 1 > > > 1 1 0 > > > > > > If a page flag is 0 and negated_flag is 1, the result would be 1 whic= h has > > > changed the page flag. It isn't making sense to me. Why the page flag= bit > > > is being fliped? > > > > > > When Anrdei had proposed these masks, they seemed like a fancy way of > > > filtering inside kernel and it was straight forward to understand. Th= ese > > > masks would help his use cases for CRIU. So I'd included it. Please c= an you > > > elaborate what is the purpose of negation? > > > > The XOR is a way to invert the tested value of a flag (from positive > > to negative and the other way) without having the API with invalid > > values (with required_flags and excluded_flags you need to define a > > rule about what happens if a flag is present in both of the masks - > > either prioritise one mask over the other or reject the call). > > (Note: the XOR is applied only to the value of the flags for the > > purpose of testing page-selection criteria.) > > Micha=C5=82, > > Your API isn't much different from the current one, but it requires > a bit more brain activity for understanding. > > The current set of masks can be easy translated to the new one: > negated_flags =3D excluded_flags > required_flags_new =3D excluded_flags | required_flags > > As for invalid values, I think it is an advantage of the current API. > I mean we can easily detect invalid values and return EINVAL. With your > API, such mistakes will be undetectable. > > As for priorities, I don't see this problem here If I don't miss somethin= g. > > We can rewrite the code this way: > ``` > if (required_mask && ((page_flags & required_mask) !=3D required_mask) > skip page; > if (anyof_mask && !(page_flags & anyof_mask)) > skip page; > if (page_flags & excluded_mask) > skip page; > ``` > > I think the result is always the same no matter in what order each > mask is applied. Hi, I would not want the discussion to wander into easier/harder territory as that highty depends on experience one has. What I'm arguing about is the consistency of the API. Let me expand a bit on that. We have two ways to look at the page_flags: A. the field represents a *set of elements* (tags, attributes) present on the page; B. the field represents a bitfield (structure; a fixed set of boolean fields having a value of 0 or 1) >From A follows the include/exclude way of API design for matching the flags, and from B the matched mask (which flags to check) + value set (what values to require). My argument is that B is consistent with how the flags are used in the kernel: we don't have operations that add or remove flags, but we have operations that set or change their value. Best Regards Micha=C5=82 Miros=C5=82aw