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 16408C6379F for ; Wed, 22 Feb 2023 11:07:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 85A406B0071; Wed, 22 Feb 2023 06:07:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E36B6B0073; Wed, 22 Feb 2023 06:07:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 65C3B6B0074; Wed, 22 Feb 2023 06:07:01 -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 4D5326B0071 for ; Wed, 22 Feb 2023 06:07:01 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EDC7D160C61 for ; Wed, 22 Feb 2023 11:07:00 +0000 (UTC) X-FDA: 80494650600.21.92F6924 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by imf06.hostedemail.com (Postfix) with ESMTP id 1349518000F for ; Wed, 22 Feb 2023 11:06:57 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=bRbbuUWQ; spf=pass (imf06.hostedemail.com: domain of usama.anjum@collabora.com designates 46.235.227.172 as permitted sender) smtp.mailfrom=usama.anjum@collabora.com; dmarc=pass (policy=reject) header.from=collabora.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677064018; a=rsa-sha256; cv=none; b=0bi0WhN8tPrtoAFBnd1Ly2CisuvesgrZAY11OLjj+HmYWZi/Kqa+tjZpDQFpLeef/kmDDo /5AvRy5AQk72NZO4U1Bj7D8MeC73TkQnvaUnVCPd6SPGhiVXw422r0wztDFsLQHTfNVMgK iF2fwZRhRPwVzfcsCUtnuNj57K9t8ZI= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=bRbbuUWQ; spf=pass (imf06.hostedemail.com: domain of usama.anjum@collabora.com designates 46.235.227.172 as permitted sender) smtp.mailfrom=usama.anjum@collabora.com; dmarc=pass (policy=reject) header.from=collabora.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677064018; 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=8Y41fcnnOnjttzdaQhZnRq/3X96n7+Jb2dQYHyQvszU=; b=ZbB8Y2jVlcX805XJwMb+TJQNeEE92Z+tsCxv0+kRqaP2a5YQQUvk5LmWngHnJoZ85ew7Rp VU/3FFDt6nU22OmHXafGR9LX4HAes63tqHZy1XnuEdAfUKbOXkJjLSY42ln5tR39CFBqmx kCLp4Rp/0PY/qS1IWlQBRQLKOIcHatw= Received: from [192.168.10.12] (unknown [39.45.217.110]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: usama.anjum) by madras.collabora.co.uk (Postfix) with ESMTPSA id A26CA66021B8; Wed, 22 Feb 2023 11:06:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1677064016; bh=QKwfpx7EO+MS89l0UxB2amnGrD9VJwiJcP8lwDdKibk=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=bRbbuUWQNiaNT2Iio02cIY6oaCZbyT3Xql2roHy2yFgEgvSuPJb49iwJXdVPFXdUu bvDTL+1/0nf8MXyjiKMOu3RMGkl+92ZR/O22bDXD81B6NHXVC528E492jaOLZOpy4s nrlI/OCKLdLEIxZ0tha2jHO+2LVa6uDPGAz/2y5vXyrdflfMLdL5ts9HmafR/2l8R1 KYX4xdwm/pYncLYPgA5SiDh8XvtQzSr1lM3YifBzYvEJAhQlk++SiQ8SEmThWC+yxn Glmyt8RyMRwMyHyYDxZvndQ2nrLvBd2V2bihYgO/eE6Y4l8h83GSvnnx/q/t/Fo+2R FF7uNovgEvfEQ== Message-ID: Date: Wed, 22 Feb 2023 16:06:25 +0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Cc: Muhammad Usama Anjum , 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 Subject: Re: [PATCH v10 3/6] fs/proc/task_mmu: Implement IOCTL to get and/or the clear info about PTEs Content-Language: en-US To: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= References: <20230202112915.867409-1-usama.anjum@collabora.com> <20230202112915.867409-4-usama.anjum@collabora.com> <36ddfd75-5c58-197b-16c9-9f819099ea6d@collabora.com> <6d2b40c6-bed9-69a6-e198-537b50953acd@collabora.com> From: Muhammad Usama Anjum In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 1349518000F X-Rspamd-Server: rspam01 X-Stat-Signature: p8pyueawucnpcwmta4abfezxpht8jua5 X-HE-Tag: 1677064017-824793 X-HE-Meta: U2FsdGVkX1/qMpoieFhkS6rNwfblZ+UOh2XLOReMoQ3d3gkCGIHQwUQLe2nDglpeLU8OsLWJm21QgvpMgZxxjdgMWS8JOhRnL6wv3uKKi/+yaUFj7V0xC9fAsXwkxI10qCWfqg66dZT9G3mtY53ZYp1cHgbsQJwHn64rxlvBuOBDU9lOQTy7ZEwGbrufQc8SJjXxPcl9nuoqNXBXwuFHUqwKdyjTUt/XuTtkimQCMUJcn2RwI3gncti/AEyJ19fZ+Ebfji3XZwo5i8rCWGF8cKXVYrKuzh2fDJJ6rJRzDFFWK7YWf9tB5Zzw3WBKwmA9awSsklFTujTr3EUjzDgm5IaKZ0fttgkoOIoIj3uF7bmGn9LFAMrB0Re5v0oz0tr2RzWJI9KVM/fceJ/78A44x+TwR+rTt9rIxfT/jz/m7F9n00WEGrDV3SxQ3M4t8iAvk8ayrBiK6TEkEvo3G/81PprO3V4zyfXPG49Bq3TOobygVMrhSdFRPjn22JorZvZnC7jOgLCHWLLwSTk0LW3aQGzaUl3um04zW7AlXQoPIETo+XUV8FP09ehoqGt4hd8orlcsYplzpmqx0kYWUJuvHSb+BGbHpxTkKA6Ds+QVysA74KkdqZABDXTcB1PRUFJW2tCPn/2snWEhDOYtwBMVIHaqAF4PGpt4DN8rcZdLsKBvBkJa3YVxAihD1AKpVhSUntDv7pkCEuYZPs3gUZlqv3UXDMoSY8ALnLCpq9LSR0N2PkAbaiZuK4Fuewar5TjRAG5oexadKRkKv/jJKoKksdTUKGUfjvq/Ate44om83uXcE1uDi8D71DX3oYRH1FAVoTdSg1sd80JaUzah/OKAJIi8BWamnUZDnhNwV2Pst7X/+Xv7yMcGrjFgCk221nsCxlBna4DmJwIpIXVjRN3pwb3Juq3hzL8RylM2TW6FGV+CD+d1vMK6wR3Rsb/xlEwqwdsLmMSUmLaaQl7gkoA 1Bk9gT57 ZQZR0l8SxY2wX2OWusrpLDlJlc/LbOpOwLRYOsg1bAmQpcGOfypGQWfN9GH6lRG5fBNpsvy/k2krwuHB6HHELUd8GZViKFwMrQNHN7F9T07NKpqU/oK8zQ7thcn3bTgX5NVaBVYt3N9C7rJohTY0GYsLJ3qSAjjf22V9YKGKC/OlmLG1H/VS7uAoIdGZOpBN/FHSBIPJ8aMZdss/0UGyS07ToTx+Jtvz2l4IeC7Rom/BiMAjOvIH3yYC2iO7iLMhaahNAMgaxPEadvNNPmF5utdMQOpYpYiy0ktqzSYwLbxsq2H9yD9G8lH2g2aLVSFjTFMF8BX5tc+mJnDCbz6lP7TwMxGBTbGSJ1JE5ltIHszfwRzZH9PSg9B9r6A== 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 2/22/23 3:44 PM, Michał Mirosław wrote: > On Wed, 22 Feb 2023 at 11:11, Muhammad Usama Anjum > wrote: >> On 2/21/23 5:42 PM, Michał Mirosław wrote: >>> On Tue, 21 Feb 2023 at 11:28, Muhammad Usama Anjum >>> wrote: >>>> >>>> Hi Michał, >>>> >>>> Thank you so much for comment! >>>> >>>> On 2/17/23 8:18 PM, Michał Mirosław 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 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. These >>>> masks would help his use cases for CRIU. So I'd included it. Please can 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). >> At minimum, one mask (required, any or excluded) must be specified. For a >> page to get selected, the page flags must fulfill the criterion of all the >> specified masks. > > [Please see the comment below.] > > [...] >> Lets translate words into table: > [Yes, those tables captured the intent correctly.] > >>> 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? >> All the masks are optional. If all or any of the 3 masks are specified, the >> page flags must pass these masks to get selected. > > This explanation contradicts in part the introductory paragraph, but > this version seems more useful as you can pass all masks zero to have > all pages selected. Sorry, I wrote it wrongly. (All the masks are not optional.) Let me rephrase. All or at least any 1 of the 3 masks (required, any, exclude) must be specified. The return_mask must always be specified. Error is returned if all 3 masks (required, anyof, exclude) are zero or return_mask is zero. > >>> 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 = page_flags ^ negated_flags; >>> // are all required flags in "active" state? [== 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; >>> >> After taking a while to understand this and compare with already present >> flag system, `negated flags` is comparatively difficult to understand while >> already present flags seem easier. > > Maybe replacing negated_flags in the API with matched_values = > ~negated_flags would make this better? > > We compare having to understand XOR vs having to understand ordering > of required_flags and excluded_flags. There is no ordering in current masks scheme. No mask is preferable. For a page to get selected, all the definitions of the masks must be fulfilled. You have come up with good example that what if required_mask = exclude_mask. In this case, no page will fulfill the criterion and hence no page would be selected. It is user's fault that he isn't understanding the definitions of these masks correctly. Now thinking about it, I can add a error check which would return error if a bit in required and excluded masks matches. Would you like it? Lets put this check in place. (Previously I'd left it for user's wisdom not to do this. If he'll specify same masks in them, he'll get no addresses out of the syscall.) > IOW my proposal is to replace branches in the masks interpretation (if > in one set then matches but if in another set then doesn't; if flags > match ... ) with plain calculation (flag is matching when equals > ~negated_flags; if flags match the masks ...). > > Best Regards > Michał Mirosław -- BR, Muhammad Usama Anjum