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 47B30C4332F for ; Tue, 8 Nov 2022 14:25:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A4F8F6B0072; Tue, 8 Nov 2022 09:25:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A001F6B0073; Tue, 8 Nov 2022 09:25:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C7886B0074; Tue, 8 Nov 2022 09:25:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7DF4E6B0072 for ; Tue, 8 Nov 2022 09:25:03 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 5B69E409C9 for ; Tue, 8 Nov 2022 14:25:03 +0000 (UTC) X-FDA: 80110496886.04.2C400D4 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by imf10.hostedemail.com (Postfix) with ESMTP id 8AB66C0005 for ; Tue, 8 Nov 2022 14:25:01 +0000 (UTC) Received: from [192.168.10.9] (unknown [39.45.244.84]) (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 3FA126602910; Tue, 8 Nov 2022 14:24:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1667917499; bh=BIWq8zC5JvLFkFz9mhkUOrHNXVqTTwKjQTgsh/1wDl8=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=akrlEx3psm3oj2NQ96EFMlQoK0A+GaJcfkzwNj2sLqG0JwNdMaNoxjZJfY49RpLZ5 nH922oXGIobtk+JUfNKyIdNw0GF8aFsLRwY3LtOYhtYqNzj6D2TphgFXBixYheGoTI z5JQCJY5DWMQrSt7y0DVaBe9L/J8RllXXmtctrmGXN1iypHINhB4mA9CxEH3uC/CXe VccYJpCh98jg0UI8HRCILt8AlvJyg6eEER73eqGkoygMzNQFaMyP8zvn5O2FQGPzEF yTKoW75RjXLlAo6heCfboYMRMpduQrAku3u62tq0Al2hehmX2k6f3SWNe7YLb+rkGD KdRzv2LnyRj+A== Message-ID: Date: Tue, 8 Nov 2022 19:24:43 +0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Cc: Muhammad Usama Anjum , Andrei Vagin , Danylo Mocherniuk , Alexander Viro , Andrew Morton , Suren Baghdasaryan , Greg KH , Christian Brauner , Peter Xu , Yang Shi , Vlastimil Babka , Zach O'Keefe , "Matthew Wilcox (Oracle)" , "Gustavo A. R. Silva" , Dan Williams , kernel@collabora.com, Gabriel Krisman Bertazi , David Hildenbrand , Peter Enderborg , "open list : KERNEL SELFTEST FRAMEWORK" , Shuah Khan , open list , "open list : PROC FILESYSTEM" , "open list : MEMORY MANAGEMENT" Subject: Re: [PATCH v5 2/3] fs/proc/task_mmu: Implement IOCTL to get and/or the clear info about PTEs To: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= References: <20221103145353.3049303-1-usama.anjum@collabora.com> <20221103145353.3049303-3-usama.anjum@collabora.com> Content-Language: en-US From: Muhammad Usama Anjum In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667917502; a=rsa-sha256; cv=none; b=yAiL/M6jcE+SXk0rdfn2TXucolPELLf1eoPfSzVNNjo1/ittSU9nmzzUSrPCwGSwLEphPo 5Ag8IAVhJay/ILMRYeJQVSZnfzMndMUcVBdnGL9g1yeDD/z5NpNCJUDtuXYAr9YZYb/i/Z 15hVaHpzp8uRgHZ42ED5zmvX8ofWgFI= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=akrlEx3p; spf=pass (imf10.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=none) header.from=collabora.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667917502; 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=R/T3zwFrMN8y1AZ4XFgU7gPCtT+cv4uRPmBTEwYjCbc=; b=ob2GnNThB9nTjo4HBzMWK1L0bL5Z+0K/vETpuiNIACjjLgAdHG4OdyZ9DbduURKdNjslhP trnRWW+sFdgIWcNFki3GlyZSmg8r9llmNLwd5yNkeliAcEVp7R/RrnFh5IcvGREK1yyrh7 nTz1zaYb4Ugnysub4U0Z8QWoG9KNhAs= Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=akrlEx3p; spf=pass (imf10.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=none) header.from=collabora.com X-Rspamd-Server: rspam12 X-Rspam-User: X-Stat-Signature: orgwqw5gsdupx9i58pofbc3thx6p6brx X-Rspamd-Queue-Id: 8AB66C0005 X-HE-Tag: 1667917501-973574 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: Hi Michał, Thank you so much for reviewing. On 11/7/22 5:26 PM, Michał Mirosław wrote: >> + >> +/* >> + * struct page_region - Page region with bitmap flags >> + * @start: Start of the region >> + * @len: Length of the region >> + * bitmap: Bits sets for the region >> + */ >> +struct page_region { >> + __u64 start; >> + __u64 len; >> + __u32 bitmap; >> + __u32 __reserved; > > "u64 flags"? If an extension is needed it would already require a new > ioctl or something in the `arg` struct. I feel like the masks must have the same type as this bitmap variable as the return_mask specifies the flags to be returned in bitmap. All the masks are of type __u32. This is why I'd kept the bitmap of type _u32 as well. I've kept them of 32 bit size as currently we are adding support for 4 flags and there is still room to add 28 more bits in the future. Do you still think that I should update the masks and bitmap to _u64? >> + * @start: Starting address of the region >> + * @len: Length of the region (All the pages in this length are included) >> + * @vec: Address of page_region struct array for output >> + * @vec_len: Length of the page_region struct array >> + * @max_pages: Optional max return pages (It must be less than vec_len if specified) > > I think we discussed that this is not counting the same things as > vec_len, so there should not be a reference between the two. The limit > is whatever fits under both conditions (IOW: n_vecs <= vec_len && > (!max_pages || n_pages <= max_pages). In worse case when pages cannot be folded into the page_region, the one page_region may have information of only one page. This is why I've compared them. I want to communicate to the user that if max_pages is used, the vec_len should be of equal or greater size (to cater worse case which can happen at any time). Otherwise in worse case, the api can return without finding the max_pages number of pages. I don't know how should I put this in the comment. > (I only reviewed the API now. The implementation I think could be > simpler, but let's leave that to after the API is agreed on.) > > Best Regards > Michał Mirosław