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 7AC3AC61DA3 for ; Tue, 21 Feb 2023 12:42:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B10F26B0071; Tue, 21 Feb 2023 07:42:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A9A336B0072; Tue, 21 Feb 2023 07:42:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 914076B0073; Tue, 21 Feb 2023 07:42:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 7B0186B0071 for ; Tue, 21 Feb 2023 07:42:44 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 4E0CD1C5AE3 for ; Tue, 21 Feb 2023 12:42:44 +0000 (UTC) X-FDA: 80491263048.24.4351E29 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by imf29.hostedemail.com (Postfix) with ESMTP id 7344212001A for ; Tue, 21 Feb 2023 12:42:42 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="cLZLuL/R"; spf=pass (imf29.hostedemail.com: domain of emmir@google.com designates 209.85.208.48 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=1676983362; 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=O6el+9joKyAhVr+TDn79fkuxzTiKR+SX0MO09engIhY=; b=sgjT/MtpIl9PtcgXc0it6shHlOA6OTjdmnjyx8JnZ23otdqa20TfYT15wqn/nEBXvxlyZs 7Gb/pLseftEkF64SxX7exFhC8fmBMQib3+oZ5gUFOanp/bG4Qr6VDNICZteQNYPYOeb3Jw fTQiecxh6SztYff3rOGPwpBdmpTODwI= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="cLZLuL/R"; spf=pass (imf29.hostedemail.com: domain of emmir@google.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=emmir@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676983362; a=rsa-sha256; cv=none; b=7hVNfPft1q5n2wpmJJxb34m4ygI3xNBOj2lOgQPf1m5nFIPoSYYhq6NsdptOpTqYvFFJZo Xy0O8jc4YC3/DKkv4qbeATvStkmEczW9wFXRj76la9x4EOkz0X79ECyTzFQD6LRAkbmvVb 6YvbPT3EfxsJktfMlPlyyFyR+MoFvwY= Received: by mail-ed1-f48.google.com with SMTP id eg37so12847938edb.12 for ; Tue, 21 Feb 2023 04:42:42 -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=O6el+9joKyAhVr+TDn79fkuxzTiKR+SX0MO09engIhY=; b=cLZLuL/REYI8EX3PmLJFdaF2YUd4XwINhRSVuCvmFL4aG05j7eoj6hTO6HsBms6J64 jI1aSNDMwXJlv7vMhzZCU57mo5E8++tN0wcL8Cp41JslegPSild6F+BHDEw87m7rLbEd U2e/JwxkCaFBy2Wd5fsup2SUZJLAAQ9sQSgQQlRq2fkj0iZmeJnegXko/ihX0PNFLSWt 56urgBxOBm/Nqy0l4t3vVRSZ0GnyJ43fsmC2tam2hSOi32ZWoe/HgEX0sPnqpynLUEyv fj0sbsXVvjHQ8Vh4esfPA0zpanqX1wvttZbt9RUFwrDvpKYVPp92lo7MQwxzTAdK/3p+ nTgQ== 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=O6el+9joKyAhVr+TDn79fkuxzTiKR+SX0MO09engIhY=; b=hGmMcaJ8/e8PJ8hg49olOE3E84lelhWjrX+JSoeMTNx47bLvpecblMhTWyp2P+our2 Iecmj1N6IMMlKlMWxjlse8xUjVChvOU897Zk0RhhFXRK5DwB/389UyqSXdSB+9xJwLJT osR3JiqvbQHxV+w5rMK5ESc/NMbhkY1q4fjP3EP3LOSMoYyiXfcZ4eOKIuvVbovjjiEn ojPe00WrnT2zoLONR6PUTsVUGPU8mV/e2j2G5mbuvLNDPnb29NUtkTWA+zN/MtRZUCOo 79zcl5Aj9VqrRf/bplQPh/8gJRT/HX2Xojovzl2MvtS9XIBAtiLO4wmtEj9pcHJbOroH shvQ== X-Gm-Message-State: AO0yUKUbSJ3zSTtUYvJeoOicCL/rtbu51gwVMNQ9VbqMoMiiI8gMZOcC 8LUqO4FIiRDsWFHH3ddHx/3lgcKTtTUmzKa3xQ/TTw== X-Google-Smtp-Source: AK7set98YYMMSbNx2hRGaTKAwlPc630Vw/Ga3pJmq4lzKkS4okWIZvm2EzW2kFQ7OPb7yFK5K2hy0cNe5M/5DCpxx9U= X-Received: by 2002:a17:906:9499:b0:8b1:79ef:6923 with SMTP id t25-20020a170906949900b008b179ef6923mr6794210ejx.15.1676983360819; Tue, 21 Feb 2023 04:42:40 -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: <36ddfd75-5c58-197b-16c9-9f819099ea6d@collabora.com> From: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= Date: Tue, 21 Feb 2023 13:42:29 +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: Muhammad Usama Anjum Cc: Andrei Vagin , 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-Server: rspam07 X-Rspamd-Queue-Id: 7344212001A X-Rspam-User: X-Stat-Signature: ktktwm1nrqmeiugjhos7y5houxxnmjwy X-HE-Tag: 1676983362-934488 X-HE-Meta: U2FsdGVkX1+q17st1NligUhoZYgIP5gQEvOzbOQJlIIDYBPmIoA//Q2q2YTDBqCUvXmyz1JGENnUV/1GE47UQgLAc4bbp889L1iOWeqmASpkYpQgF5PqjOYgQwPQKBAM/OIadg2xdxppTspTYdIJiUOSRZn3kU20it0vZBUtlby33ZiqwtgTVYG9QhOxyaLMwB75iBvss3pY9G08aCWyqZ5PT6yLw+Ovuccvyze8v31Tn4W3t1IhtGohVWx/KOm4xp+NI8nfY6tWmFhL6KQCUREwFbyIyFS6L0kpdqRv42l2/VJSRojp4xPo2Gd0aSS9KzeQAxTHq9pQ8oW8HrIsL3jNQQenn1eHF+uqzZZF43Gnyn+hZDwnA0PX81wpWw/MmrZCMoCBJf0ExCEjHnWIhOVXV5PZck37MaKvaTvEza6Ri8/3UR21/TdhbTNIaAiHGPBnEIb/F+8eSmifcBVuVxTZhF1Cn0TVjt8z9zbjOof76eofhUMr6JPuVocW6Wcud9KkxedjvuSp62Jx8sUdvgx/TuttdBixanW6JHymxRvYpL6u8MWVChc97Io7nwmCybHHb5uBHbomfyywHXXiui3wSFjhJ9KTqPHQo6U+O7AL4tCmSerQP64KXrZyF2TcGzKTrtK/Q9nXHwmgUnj9AhcDLwD36WUGZZv6Pc3UOYc7oa9fdZtoTkdgCcGhRACMNb1XPhKF7YT/RxELVAeJmFGcmFQIzt98PxjiZPjstkSBGAxgH9WxmPxjMMHEQaYSbmc2tquMTTbrBELXFklY2j8DH9Oij2rR0SekcmBiEBUcG9PVSPGpzdj1k+rrPYsYl54lPXJsP5+P/BWiQawXzaZAetvaQZVVbufLQ8IZTMiIwL9hY5GI1xGH7dZi2hbCmOXBi+Qa97CE0TRjvRNCK2dy4TGRxRVsZSvMmXmuByB1QDgrF9DGBI4TAcPPvL8lOLAsuUr9If8AlT8choj nB9YgZ5h 1ubFfwBITgf82YyAOIZqRq2T5MoG75SQaDeVmYQyUJJ0dq3sUYI3NXssbeIom0IDOZpf/Z95eqvy0qx3wshy0tFHWmP9UAL9QcxeDV6UK3Y0PixwUVB5jMo6dKv30fCzxkGK5Bkw5remRgvJpgh1rkxCM5+ha3af8k+c+5C38DN5jtRRj0YRnzpqPAO1xp06iIrNnVnlBjAV4QQJXIiTrZIlpH56Yfi6ElYYjzkdjUehioEqQ9N1r87sHJYpwjLKbVhhdS2XOigkxtGq0zulOUwixRHbRHOwG/0XlRYsZlApFwFvTaTGy2ztxqSFOqpLzNOEM7wXXRbWMyanH72Yu3MfMiKo+oRySBlct7MbEaK1/Mx5ouRu4e7lZs/LVD5Ima/2QCNVjJafa7R7TE8kWQaKUWlpLXJgZPYJfg/E7q6c8/5ksGdMmpy+FWZNRQjKwbBb9FsJLcVzErgY= 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 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 selected= . > All the set bits in excluded_mask must _not_ be set for the page to be > selected. > > > responsibilities. I suggest to rework that to: > > 1. negated_flags: page flags which are to be negated before applying > > the page selection using following masks; > Sorry I'm unable to understand the negation (which is XOR?). Lets look 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 which ha= s > 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. These > masks would help his use cases for CRIU. So I'd included it. Please can y= ou > 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.) So: 1. if a flag is not set in negated_flags, but set in required_flags, then it means "this flag must be one" - equivalent to it being set in required_flag (in your current version of the API). 2. if a flag is set in negated_flags and also in required_flags, then it means "this flag must be zero" - equivalent to it being set in excluded_flags. The same thing goes for anyof_flags: if a flag is set in anyof_flags, then for it to be considered matched: 1. it must have a value of 1 if it is not set in negated_flags 2. it must have a value of 0 if it is set in negated_flags BTW, I think I assumed that both conditions (all flags in required_flags and at least one in anyof_flags is present) need to be true for the page to be selected - is this your intention? The example code has a bug though, in that if anyof_flags is zero it will never match. Let me fix the selection part: // calc. a mask of flags that have expected ("active") values tested_flags =3D page_flags ^ negated_flags; // are all required flags in "active" state? [=3D=3D all zero when negated] if (~tested_flags & required_mask) skip page; // is any extra flag "active"? if (anyof_flags && !(tested_flags & anyof_flags)) skip page; Best Regards Micha=C5=82 Miros=C5=82aw