Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp7120056rwb; Tue, 6 Dec 2022 01:10:31 -0800 (PST) X-Google-Smtp-Source: AA0mqf5lvC2OQbNPBUnYsCCQI5Gfqnty2MK0tof28RQMMs5n6igkXM9BsciYZ/0AJcmII41OLEMw X-Received: by 2002:a17:906:eb41:b0:7b6:ff1c:c4f0 with SMTP id mc1-20020a170906eb4100b007b6ff1cc4f0mr57585181ejb.359.1670317830937; Tue, 06 Dec 2022 01:10:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670317830; cv=none; d=google.com; s=arc-20160816; b=hbOzqVuCg/nwolPKvB9u9Scxs/a+LC+nGnX+JkKWsQn2llph8QamEu0EzhRB2+/OJn YTTmrvE8uaqFoKdQ5Bl49WGTvaY0WBenDMMIL00UOqrEbZ7lZmpJ/cS86mY7iXInpMCC M9k8alXeqGNZxUdHbnKyBkfrE7CJ+wdEeWm1vamkFu2Y5NH8rVnwZPzkOabTal6vP3As FbDDXAw+/R5F8ihQIw715DIouE9XDtUqEgHp5Apto2yQLTBE2ax9tew4tKO86fDacY6J ux4UfyYM/VBWFyGs7K2T99fboJUjjKOE0UB06AWZZ0WWsHC4vA4vG4bA69TWAcq9nCxb 9vlw== 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:subject :organization:from:content-language:references:cc:to:user-agent :mime-version:date:message-id:dkim-signature; bh=rchCSzvIhJmofJ14lURjIDvExoo3wjMkCA1LFuzN0Nw=; b=husQUC32S+yDOfyZuog7usVjCxikYi8/oIUvCI8F8Z5wYzl8atY/0vO8tzXwEiBmmY S7PeJekbRXk2O9zcpAmOzb3Tds3yjnwLvlxow36+qQMvIe1yuvJP1y0/an0YRfpcodw8 TEeBV0SXOvn8dH/2T4abXIrjMtbF0Y6k1zBLunADK5l/dEekssnhTTwM/3/ET4ZLPhCR Djyuf+6hKZ1Aq4ZNcj66xMxMqn8t4T5hXObp2T1ybYzM038VLVGTe1XU5Ih65KV2Fbww R27UxvTotx5wIVMe5H9nOS5aHYFXIpyUMTis8uhzTTcKDPic3ek4wyd2AgKQIY7sPsFk Ox5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LW7l5S2z; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bc26-20020a056402205a00b004608c0b9a8asi1389133edb.201.2022.12.06.01.10.11; Tue, 06 Dec 2022 01:10:30 -0800 (PST) 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=@redhat.com header.s=mimecast20190719 header.b=LW7l5S2z; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233668AbiLFIpE (ORCPT + 79 others); Tue, 6 Dec 2022 03:45:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232321AbiLFIpB (ORCPT ); Tue, 6 Dec 2022 03:45:01 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 967A0D12B for ; Tue, 6 Dec 2022 00:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670316244; 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=rchCSzvIhJmofJ14lURjIDvExoo3wjMkCA1LFuzN0Nw=; b=LW7l5S2zXOSaddFBvOFXYeTe9L/SBLqjZmvkrU/YUOLiiIaBZuD71ghepxC3rmv5zvT87x NynVg6oCNxldYQ3oUCOKIOIhNmDEzpnqTU87gqpIldyr0FXdhrQCzaOUjrx6n88zBXIw5l jqp9o4XEtghnUchekO0+eCArE05omTQ= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-631-WfxSc0H7PfqxIEoFfUDY3g-1; Tue, 06 Dec 2022 03:44:03 -0500 X-MC-Unique: WfxSc0H7PfqxIEoFfUDY3g-1 Received: by mail-wr1-f69.google.com with SMTP id w11-20020adfbacb000000b002418a90da01so2970663wrg.16 for ; Tue, 06 Dec 2022 00:44:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :content-language:references:cc:to:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rchCSzvIhJmofJ14lURjIDvExoo3wjMkCA1LFuzN0Nw=; b=J21hf7MjSlIzZr6Rm1l4qmQq97ro8tRamZuPfda6sYOcDUnB8qv8KE0u/gjZQKy17s kkr2qt5Z37drkW4yaiB6oeuubGESi3ie6OxEu+GqpzNKsqqvncO04CMWr0tzGQNeMFm2 ugCkZ30aub9qor6W+mr4Mji8jnbJtCqc9CpFCLmZZixDVlKm5aMwnIAdlhBBMt7+OviA NT8Y3AMHijpeqThf0RP61PjcV+V1h2pL4jQ0E8PL3L6GR2FYa85tEM+LSMB1kEY0Gp6f pHhquZfMpvtUNnpm2PAv83QBJ26AA4UL/5POPEqqWRATH2do+j+yAzOXLlYn9OEbDD7w BbLQ== X-Gm-Message-State: ANoB5pksdiflZm3JL79Ks3g9roZgyfVvmIXsjdhUzT+LkdedaGqsYqe7 LibUunZEoJqXmLJnVXSvqlRzEuHxB8CPXRmfgoSdI8xAAiNE5O2/j8Hc6z0s1S9xg5u2vIL/9cH kwRDPptf1jLxZU+EZ6H/gETsU X-Received: by 2002:a05:600c:2284:b0:3d0:837c:8561 with SMTP id 4-20020a05600c228400b003d0837c8561mr13530507wmf.168.1670316242129; Tue, 06 Dec 2022 00:44:02 -0800 (PST) X-Received: by 2002:a05:600c:2284:b0:3d0:837c:8561 with SMTP id 4-20020a05600c228400b003d0837c8561mr13530479wmf.168.1670316241747; Tue, 06 Dec 2022 00:44:01 -0800 (PST) Received: from ?IPV6:2003:cb:c705:4f00:41f1:185d:4f9f:d1c2? (p200300cbc7054f0041f1185d4f9fd1c2.dip0.t-ipconnect.de. [2003:cb:c705:4f00:41f1:185d:4f9f:d1c2]) by smtp.gmail.com with ESMTPSA id h16-20020a05600c2cb000b003c6bbe910fdsm30281604wmc.9.2022.12.06.00.43.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Dec 2022 00:44:01 -0800 (PST) Message-ID: <3c7fd5da-b3f8-5562-45a9-f83d7dbcdd7d@redhat.com> Date: Tue, 6 Dec 2022 09:43:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 To: Miaohe Lin , linux-kernel@vger.kernel.org Cc: Andrew Morton , Hugh Dickins , Linus Torvalds , David Rientjes , Shakeel Butt , John Hubbard , Jason Gunthorpe , Mike Kravetz , Mike Rapoport , Yang Shi , "Kirill A . Shutemov" , Matthew Wilcox , Vlastimil Babka , Jann Horn , Michal Hocko , Nadav Amit , Rik van Riel , Roman Gushchin , Andrea Arcangeli , Peter Xu , Donald Dutile , Christoph Hellwig , Oleg Nesterov , Jan Kara , Liang Zhang , Pedro Gomes , Oded Gabbay , linux-mm@kvack.org References: <20220428083441.37290-1-david@redhat.com> <20220428083441.37290-13-david@redhat.com> <90dd6a93-4500-e0de-2bf0-bf522c311b0c@huawei.com> Content-Language: en-US From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v4 12/17] mm: remember exclusively mapped anonymous pages with PG_anon_exclusive In-Reply-To: <90dd6a93-4500-e0de-2bf0-bf522c311b0c@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham 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 >> > > Hi David, sorry for the late respond and a possible inconsequential question. :) Better late than never! Thanks for the review, independently at which time it happens :) > > > >> diff --git a/mm/hugetlb.c b/mm/hugetlb.c >> index 7a71ed679853..5add8bbd47cd 100644 >> --- a/mm/hugetlb.c >> +++ b/mm/hugetlb.c >> @@ -4772,7 +4772,7 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, >> is_hugetlb_entry_hwpoisoned(entry))) { >> swp_entry_t swp_entry = pte_to_swp_entry(entry); >> >> - if (is_writable_migration_entry(swp_entry) && cow) { >> + if (!is_readable_migration_entry(swp_entry) && cow) { >> /* >> * COW mappings require pages in both >> * parent and child to be set to read. >> @@ -5172,6 +5172,8 @@ static vm_fault_t hugetlb_cow(struct mm_struct *mm, struct vm_area_struct *vma, >> set_huge_ptep_writable(vma, haddr, ptep); >> return 0; >> } >> + VM_BUG_ON_PAGE(PageAnon(old_page) && PageAnonExclusive(old_page), >> + old_page); >> >> /* >> * If the process that created a MAP_PRIVATE mapping is about to >> @@ -6169,12 +6171,17 @@ unsigned long hugetlb_change_protection(struct vm_area_struct *vma, >> } >> if (unlikely(is_hugetlb_entry_migration(pte))) { >> swp_entry_t entry = pte_to_swp_entry(pte); >> + struct page *page = pfn_swap_entry_to_page(entry); >> >> - if (is_writable_migration_entry(entry)) { >> + if (!is_readable_migration_entry(entry)) { > > In hugetlb_change_protection(), is_writable_migration_entry() is changed to !is_readable_migration_entry(), > but > >> pte_t newpte; >> >> - entry = make_readable_migration_entry( >> - swp_offset(entry)); >> + if (PageAnon(page)) >> + entry = make_readable_exclusive_migration_entry( >> + swp_offset(entry)); >> + else >> + entry = make_readable_migration_entry( >> + swp_offset(entry)); >> newpte = swp_entry_to_pte(entry); >> set_huge_swap_pte_at(mm, address, ptep, >> newpte, huge_page_size(h)); > > > >> diff --git a/mm/mprotect.c b/mm/mprotect.c >> index b69ce7a7b2b7..56060acdabd3 100644 >> --- a/mm/mprotect.c >> +++ b/mm/mprotect.c >> @@ -152,6 +152,7 @@ static unsigned long change_pte_range(struct vm_area_struct *vma, pmd_t *pmd, >> pages++; >> } else if (is_swap_pte(oldpte)) { >> swp_entry_t entry = pte_to_swp_entry(oldpte); >> + struct page *page = pfn_swap_entry_to_page(entry); >> pte_t newpte; >> >> if (is_writable_migration_entry(entry)) { > > In change_pte_range(), is_writable_migration_entry() is not changed to !is_readable_migration_entry(). Yes, and also in change_huge_pmd(), is_writable_migration_entry() stays unchanged. > Is this done intentionally? Could you tell me why there's such a difference? I'm confused. It's very > kind of you if you can answer my puzzle. For change protection, the only relevant part is to convert writable -> readable or writable -> readable_exclusive. If an entry is already readable or readable_exclusive, there is nothing to do. The only issues would be when turning a readable one into a readable_exclusive one or a readable_exclusive one into a readable one. In hugetlb_change_protection(), the "!is_readable_migration_entry" could in fact be turned into a "is_writable_migration_entry()". Right now, it would convert writable -> readable or writable -> readable_exclusive AND readable -> readable AND readable_exclusive -> readable_exclusive, which isn't necessary but also shouldn't hurt either. So yeah, it's not consistent but shouldn't be problematic. Do you see an issue with that? It would be great to extend the "selftest/vm cow" test to also cover migration entries, however, that requires slightly more work and "luck" to fork() while migration is happening. Thanks! -- Thanks, David / dhildenb