Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp1278645rwd; Thu, 15 Jun 2023 08:29:09 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7TWrff81Sr9R+hTRBg8nm+dP5c5+rXxlPGYPRus622tHXlDLnNVp7GD0I/U+2jOTJr7tCA X-Received: by 2002:a05:6a20:7f99:b0:110:c8f:b53b with SMTP id d25-20020a056a207f9900b001100c8fb53bmr4344071pzj.62.1686842949708; Thu, 15 Jun 2023 08:29:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686842949; cv=none; d=google.com; s=arc-20160816; b=rEITKR6VFaA10Q6BOP1yPWV0pLBxFabQTLd9sd4NLIl23YjPSAg9qGcktNORe5GQdz mdor2L4U8FOz7E9mYWtNt0zPx/A3yxvu7bE/CqtegVUq6dsLYY7OtO7AzqPT5pCI7KQE eMlc9/y5KZXZHWd1EmM8a6wTJOAZtLNBdyrhanR7KG5iQbo/xpBHwUNlgtkNOxjY9jJl 52xjNJIsJMNkYIcITpPlB1ZprrfQgD9DY6MbLL1deMgw1ipbG7YNmLd69+yUiow2yayc AWrz77aB0rKQ5d51mQcDArurmijZecu8Omhd/vJLPjEwygfsxI7LuC7X78EkcjQhN+M3 dHgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:to:content-language:subject:cc:user-agent:mime-version :date:message-id:dkim-signature; bh=CP7AzKKCujx3rQ/4RAt2G9arnmtRWEa1ud20aOzPNrc=; b=Zb8NffqjxH6emBI1cF+TozBFan8OlEGNvnkWk75FD9c5t3n9gc4shFS0bebLhjsl7L Hst/D/OMclbKIm/lgGvKChObrZ4c4Bky7AQKsiEVPxF3Jwr+po2yzRLOT/xW7QH/FBIm dj0FmW1kymZwmBjge6tCySA7cPo7KvHPRcZjk81YFOAH5Ob9RVYCle0UD0ceJ9Fw8a/3 kTIrWTZJR3RbNuHDnnRrvW8DXjXC8SAOZq1IgJY6y17VydVXm1J5ijO+B5PEpNC7cmLo z7FMkkCX4YfwH/yfofdXICIjM6oeVsPIItqnXCw0nLyjW4tl/aPg/0nD23GybUOaYkWl WyLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b="biOA/gL+"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x27-20020aa78f1b000000b0065b4e2b52c6si13246477pfr.341.2023.06.15.08.28.56; Thu, 15 Jun 2023 08:29:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b="biOA/gL+"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345040AbjFOPQf (ORCPT + 99 others); Thu, 15 Jun 2023 11:16:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345038AbjFOPQ0 (ORCPT ); Thu, 15 Jun 2023 11:16:26 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 315B22D5D; Thu, 15 Jun 2023 08:16:22 -0700 (PDT) Received: from [192.168.10.55] (unknown [119.155.33.163]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: usama.anjum) by madras.collabora.co.uk (Postfix) with ESMTPSA id E82676606F67; Thu, 15 Jun 2023 16:16:13 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1686842180; bh=C0LEQtiOTpGeaCKA+5bOCExcFaAsKTYF2+EXB06sxLI=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=biOA/gL+FCKC1STuGTkA27txM7KGqLoOY5QAg/CEkPhfmvwgSp4HyueREBL5JRNqo qj12DWxyl8+iwhbx1is/3rVI2TgwihjblFnKhEiwT0CRQe3bsZ3A7MLBi5IYFik1CN bWkEmO3IjEfyzzb4s4qY6hubBX69vPgsH1+O+Tarr0UCdZyItIpbnGFzdV4YDfksk8 NqAoN9vn37M6FC8PW9CQdX98oLmDNfisTmkUh5PmujzhkiCnydIez85QLaRm9IvmpL u2atqKkAwbY2FkCQs5XbUXDoZYn6hm32m9VEfdXIvulNOYgh4UaDN+Cmu/vG2VaUM/ +x8t9wZ93KyZA== Message-ID: <43c96533-8009-e42f-721c-4b2d1e142f5d@collabora.com> Date: Thu, 15 Jun 2023 20:16:10 +0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Cc: Muhammad Usama Anjum , 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 Subject: Re: [PATCH v18 2/5] fs/proc/task_mmu: Implement IOCTL to get and optionally clear info about PTEs Content-Language: en-US To: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= 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> From: Muhammad Usama Anjum In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_SORBS_WEB, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Please review the v19. I hope to get your reviewed by tag soon. On 6/15/23 7:58 PM, Michał Mirosław wrote: > On Thu, 15 Jun 2023 at 16:52, Michał Mirosław 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 PM, Michał Mirosław wrote: >>>> (A quick reply to answer open questions in case they help the next version.) >>>> >>>> On Wed, 14 Jun 2023 at 19:10, Muhammad Usama Anjum >>>> wrote: >>>>> On 6/14/23 8:14 PM, Michał Mirosław wrote: >>>>>> On Wed, 14 Jun 2023 at 15:46, Muhammad Usama Anjum >>>>>> wrote: >>>>>>> >>>>>>> On 6/14/23 3:36 AM, Michał Mirosław wrote: >>>>>>>> On Tue, 13 Jun 2023 at 12:29, Muhammad Usama Anjum >>>>>>>> wrote: >>>>>>>> For flags name: PM_REQUIRE_WRITE_ACCESS? >>>>>>>> Or Is it intended to be checked only if doing WP (as the current name >>>>>>>> suggests) and so it would be redundant as WP currently requires >>>>>>>> `p->required_mask = PAGE_IS_WRITTEN`? >>>>>>> This is intended to indicate that if userfaultfd is needed. If >>>>>>> PAGE_IS_WRITTEN is mentioned in any of mask, we need to check if >>>>>>> userfaultfd has been initialized for this memory. I'll rename to >>>>>>> PM_SCAN_REQUIRE_UFFD. >>>>>> >>>>>> Why do we need that check? Wouldn't `is_written = false` work for vmas >>>>>> not registered via uffd? >>>>> UFFD_FEATURE_WP_ASYNC and UNPOPULATED needs to be set on the memory region >>>>> for it to report correct written values on the memory region. Without UFFD >>>>> WP ASYNC and UNPOUPULATED defined on the memory, we consider UFFD_WP state >>>>> undefined. If user hasn't initialized memory with UFFD, he has no right to >>>>> set is_written = false. >>>> >>>> How about calculating `is_written = is_uffd_registered() && >>>> is_uffd_wp()`? This would enable a user to apply GET+WP for the whole >>>> address space of a process regardless of whether all of it is >>>> registered. >>> I wouldn't want to check if uffd is registered again and again. This is why >>> we are doing it only once every walk in pagemap_scan_test_walk(). >> >> There is no need to do the checks repeatedly. If I understand the code >> correctly, uffd registration is per-vma, so it can be communicated >> from test_walk to entry/hole callbacks via a field in >> pagemap_scan_private. > > Actually... this could be exposed as a page category for the filter > (e.g. PAGE_USES_UFFD_WP) and then you could just make the ioctl() to > work for your usecase without tracking the ranges at the userspace > side. I'm not sure about page category. ASAIK the current check isn't bad when we already mention in documentation that memory must be registered with UFFD WP before using write feature of the IOCTL. Just like mincore mentions in documentation that user buffer will be filled with values based on the length of the region. Kernel doesn't care if user had provided smaller buffer and kernel overwrites because of user's own issue. I want to follow the same path. If user doesn't read documentation and follow it, he should be punished with the error. > > Best Regards > Michał Mirosław -- BR, Muhammad Usama Anjum