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 95BEEC636D4 for ; Wed, 15 Feb 2023 21:12:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2B07C6B0071; Wed, 15 Feb 2023 16:12:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 23A3E6B007B; Wed, 15 Feb 2023 16:12:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 03DBC6B007D; Wed, 15 Feb 2023 16:12:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E4D7A6B0071 for ; Wed, 15 Feb 2023 16:12:25 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A2EAB41158 for ; Wed, 15 Feb 2023 21:12:25 +0000 (UTC) X-FDA: 80470774650.21.47EFD7B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf15.hostedemail.com (Postfix) with ESMTP id 6DBE4A0019 for ; Wed, 15 Feb 2023 21:12:23 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=WaEx0tCJ; spf=pass (imf15.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676495543; 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=6sdUXKXxrfW+mAzuTBhSKEe6d+lBQL+20Mwbq3MLzH8=; b=Xt5r2G3w206L0C7L8c+KAXbVSWIjmykfPf38ok7clsXXboqGAxod7iudeTzosEGTzyNk0h 945CgQIeJAkh6mvU29KeyUtqtVZyw/RRGM7SRafOfIIhir7LvblVuScSqtllqv+EZ6GbXv 1EBKa1QMDxEtpwOvNWLRCNG6SG/76iA= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=WaEx0tCJ; spf=pass (imf15.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676495543; a=rsa-sha256; cv=none; b=mZ+9+XDjj5LfaYOTRmLn/4yT0ij1Zn4+8vPAKH1tF5FQ2Fcw4yJybCtmjKPAwwCbocwScw dNp5IqpeiyMOrJ6T9hgegAApM5mtgBTI4DveJidQOyKINNDKC2cGrg+1TDm2xEI6HpFc+Q pfgzMlZu5NJBOBbaLOX3tkagCU+sxtM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676495542; h=from:from: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; bh=6sdUXKXxrfW+mAzuTBhSKEe6d+lBQL+20Mwbq3MLzH8=; b=WaEx0tCJod9Am7e/R2YdAYCF0wGi0oiYiWNri1SUXM3dl1ZXx/68FYNnLKLdcJUOGqGSOM eXnXmVisYzJ0ufj2hFPUf8HuqCUl+gPJMUQuApyicvFDOzrndSIx9L3DAurjSY6sf7OW8s w4hBuJvy5fb2/lWTDTqZFBptP8kw55w= Received: from mail-il1-f199.google.com (mail-il1-f199.google.com [209.85.166.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-527-bN3KiOzIPN2Smdh_XO4Fmg-1; Wed, 15 Feb 2023 16:12:21 -0500 X-MC-Unique: bN3KiOzIPN2Smdh_XO4Fmg-1 Received: by mail-il1-f199.google.com with SMTP id s5-20020a92cb05000000b003153437796fso133241ilo.8 for ; Wed, 15 Feb 2023 13:12:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6sdUXKXxrfW+mAzuTBhSKEe6d+lBQL+20Mwbq3MLzH8=; b=G/qSHq1uJJG+IduI8I+ulBkqjl4G3ks4nXgjmAxPzWAUqaUBEeF7aMojzp+wBuyJjg B/9r9aIu4J3j9d4KucI1MbPJAAkjBlyJL4C7OAQ7PHLeYSZEqnSF2/+8P0OtYLYGdqf4 Nqszg4q+biA3RsSha+gFnaAkH5AZbTNFE6Oqa9wylEd+VEQcYaDbRZokGGkK8F6lwnWQ eCq1UX605SFfI2j6NoFc/NtUt/iK/wu+fxGyxVH2+SPjOE55/er5K177z9Vz7eO+Whjn r73Dp6UFICAFw/NbttsES3D5LOWcJpCgUHBVFFyd41GzjStEcCSDudWYXfnOzsGZe8Yj 8DQQ== X-Gm-Message-State: AO0yUKXJUETZ76Rhq3FKpYA0HIjJ4Ymk/r0Wl8wMf9LHsZPr4mKjRkXM wj7Infd9py/NZcTonDf/Eu0G/ZxC5FTqqz2UAnQhqpsz1bWaqslYGIZbrGriRhPCnp9eVMeUCbl M9A9pXJuf2GQ= X-Received: by 2002:a05:6e02:180a:b0:314:1579:be2c with SMTP id a10-20020a056e02180a00b003141579be2cmr3158011ilv.0.1676495540759; Wed, 15 Feb 2023 13:12:20 -0800 (PST) X-Google-Smtp-Source: AK7set9YvaTULu4TJGwUvbRrKZO6FUCyDczd5c1ykfW4fd3xdBJS63A1AOfZuvkOfpTEmmxuCSkuUA== X-Received: by 2002:a05:6e02:180a:b0:314:1579:be2c with SMTP id a10-20020a056e02180a00b003141579be2cmr3157998ilv.0.1676495540462; Wed, 15 Feb 2023 13:12:20 -0800 (PST) Received: from x1n (bras-base-aurron9127w-grc-56-70-30-145-63.dsl.bell.ca. [70.30.145.63]) by smtp.gmail.com with ESMTPSA id f3-20020a02b783000000b003b1d7fbf810sm1542836jam.148.2023.02.15.13.12.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Feb 2023 13:12:19 -0800 (PST) Date: Wed, 15 Feb 2023 16:12:17 -0500 From: Peter Xu To: Muhammad Usama Anjum Cc: David Hildenbrand , Andrew Morton , =?utf-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= , Andrei Vagin , Danylo Mocherniuk , Paul Gofman , Cyrill Gorcunov , Alexander Viro , Shuah Khan , Christian Brauner , Yang Shi , Vlastimil Babka , "Liam R . Howlett" , Yun Zhou , Suren Baghdasaryan , Alex Sierra , Matthew Wilcox , Pasha Tatashin , Mike Rapoport , Nadav Amit , 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 v10 3/6] fs/proc/task_mmu: Implement IOCTL to get and/or the clear info about PTEs Message-ID: References: <20230202112915.867409-1-usama.anjum@collabora.com> <20230202112915.867409-4-usama.anjum@collabora.com> <8b2959fb-2a74-0a1f-8833-0b18eab142dc@collabora.com> <39217d9a-ed7e-f1ff-59b9-4cbffa464999@collabora.com> <884f5aa6-5d12-eecc-ed71-7d653828ca20@collabora.com> MIME-Version: 1.0 In-Reply-To: <884f5aa6-5d12-eecc-ed71-7d653828ca20@collabora.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 6DBE4A0019 X-Stat-Signature: 66e7y3hxx4bjuibdrn68ep31s6xk4to6 X-Rspam-User: X-HE-Tag: 1676495543-725835 X-HE-Meta: U2FsdGVkX19d03GkpQ9gQxY7DzsSg0305j3T6s2D0bZQFL1zpRb7W1LlpBjX7qMFUNwNcObA2iYCjZEPtcY6hxB0pKevztGYOj+yf+HAdhA5xQnGPBUYw9bLUihmvyCdHiOn5Om7MbTZtg/gpKvWH1B3jDk4Hcc0EI7mVRqMb297vUz2/q92ChaY/hLfxqq68/dPqS9IhcFxylPCozW86OEC5Bhz3VScgfO3/1mCQzmC53FuGk9hwruxORo5J78fNYlYj8lTem8QhioaYATKfHAg6mM5YKaUE/O1MPJ+6okiCvIYTPV8dLMBopSa4FIP/N0r8MUQw4NgQwWJfTaJGoRvi1XBfb1TkdVNjfS83ocZvA3zNJzCn+IZqCLXiFSDoqv6sKD8btAsUXWs8VpuyJvVXyD7TvEPJ066jvoRnOPGq6IzEeRX31nGZY6ZFNkhCJS5IyARQqRLjn5++RHIh1H1772vamr227N2454qX2xkoHMN1SbirtjjO5F7HQrnec620rM/jShkNxzoUPisC/IDoLMF2sesYOOWNW2OzualgR5ZPp9pubckTvAOPbNZ9uotNAjEaOjHtbKcyyh7vhBWMs+9Y0KbnzDtSCfHFOpwc8Dg9CehUYTPSLN6/mi8xTSjeNb1LFBwMpMNO3wFuYVn5L2oC3Iz+5qtoCyN0ThTXZF84/vVhB5/bvKpS30/HW7P4DkV+M8zBtIdZOPL22b1+ZojoqK8oJj7/WY8evmrVJsE/SDoN2ZGk0I9isFPTz3JV8h+tOErjWpxR66p/LMT1lJx0xaN8KT+kpWUUA0UtiTtnor+2lBfMwuGYSAl0EpaGq+7IiAjp+nBTiuTkzmLLqVeXwsDz83U1EvqETumucoAtiBaW/exetpQv7GUJHjR/vHLjWL4PRkJ+n4CmOF4YSpmGM+7KlQCg0gKVxe6v7ZfkKfLJAtgREUjohzdmNJXfDkcoSdpirM0SbJ CKGqyXnY rweI2TGqs/vJxXOFS/sGvSCj0QyBN4+GNKyF4lgro59CBsJ8QYEIrXqz1S02iSycZ1DxfEFlpDWREUhPt+YHmDwnU/eVvbnlapC3HlZF7UF4TFvGAjpzSCpzBLatzBQiu6nPPqlqDZ6U1aSV0z5Bc4T9YFO5uTYg2gK32EnTfKlXsOpM1KRngYhllpB9HI9BrIZDuKZjCEDUGB4zHwLr53weOF0FxHJfwjFsm6PWjRAphyHyp4cx2MTvGoa1NTkC3UowtJ9fPA9WS8Q27eqm1AkquNt7ssz3Cn2o5QfgdRs2NwUHvoGBDK5hdsTjhAGcJfH8eyotq/JDj6jaiHOMX5yIsQEpV/UTJOZS8wIUT+LkdfcrRSAZDyGGL0DFJ33zxytydTNUk4Voatl2BHvJKpStPN6uDqeBYqXh3dCGIb0uWjZfAYoCHObOCwkcuYZ0uj7vr0VT+Nqcn16xfISA0E4oi82dfUOxSevm+uqdcNs6u2GxthGMgBKAWGGUkbY2wGQBs 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 Wed, Feb 15, 2023 at 03:03:09PM +0500, Muhammad Usama Anjum wrote: > On 2/15/23 1:59 AM, Peter Xu wrote: > [..] > >>>> static inline bool is_pte_written(pte_t pte) > >>>> { > >>>> if ((pte_present(pte) && pte_uffd_wp(pte)) || > >>>> (pte_swp_uffd_wp_any(pte))) > >>>> return false; > >>>> return (pte_present(pte) || is_swap_pte(pte)); > >>>> } > >>> > >>> Could you explain why you don't want to return dirty for !present? A page > >>> can be written then swapped out. Don't you want to know that happened > >>> (from dirty tracking POV)? > >>> > >>> The code looks weird to me too.. We only have three types of ptes: (1) > >>> present, (2) swap, (3) none. > >>> > >>> Then, "(pte_present() || is_swap_pte())" is the same as !pte_none(). Is > >>> that what you're really looking for? > >> Yes, this is what I've been trying to do. I'll use !pte_none() to make it > >> simpler. > > > > Ah I think I see what you wanted to do now.. But I'm afraid it won't work > > for all cases. > > > > So IIUC the problem is anon pte can be empty, but since uffd-wp bit doesn't > > persist on anon (but none) ptes, then we got it lost and we cannot identify > > it from pages being written. Your solution will solve problem for > > anonymous, but I think it'll break file memories. > > > > Example: > > > > Consider one shmem page that got mapped, write protected (using UFFDIO_WP > > ioctl), written again (removing uffd-wp bit automatically), then zapped. > > The pte will be pte_none() but it's actually written, afaiu. > > > > Maybe it's time we should introduce UFFD_FEATURE_WP_ZEROPAGE, so we'll need > > to install pte markers for anonymous too (then it will work similarly like > > shmem/hugetlbfs, that we'll report writting to zero pages), then you'll > > need to have the new UFFD_FEATURE_WP_ASYNC depend on it. With that I think > > you can keep using the old check and it should start to work. > > > > Please let me know if my understanding is correct above. > Thank you for identifying it. Your understanding seems on point. I'll have > research things up about PTE Markers. I'm looking at your patches about it > [1]. Can you refer me to "mm alignment sessions" discussion in form of > presentation or if any transcript is available? No worry now, after a second thought I think zero page is better than pte markers, and I've got a patch that works for it here by injecting zero pages for anonymous: https://lore.kernel.org/all/20230215210257.224243-1-peterx@redhat.com/ I think we'd also better to enforce your new WP_ASYNC feature bit to depend on this one, so fail the UFFDIO_API if WP_ASYNC && !WP_ZEROPAGE. Could you please try by rebasing your work upon this one? Hope it'll work for you already. Note again that you'll need to go back to the old is_pte|pmd_written() to make things work always, I think. [...] > I truly understand how you feel about export_prev_to_out(). It is really > difficult to understand. Even I had to made a hard try to come up with the > current code to avoid consuming a lot of kernel's memory while giving user > the compact output. I can surely map both of these with a dirty looking > macro. But I'm unable to find a decent macro to replace these. I think I'll > put a comment some where to explain whats going-on. So maybe I still missed something? I'll read the new version when it comes. Thanks, -- Peter Xu