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 818ECC47071 for ; Thu, 16 Nov 2023 10:03:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F25036B0445; Thu, 16 Nov 2023 05:03:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ED56E6B0447; Thu, 16 Nov 2023 05:03:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D28226B0448; Thu, 16 Nov 2023 05:03:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C2FAF6B0445 for ; Thu, 16 Nov 2023 05:03:50 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9B0CBB5EDF for ; Thu, 16 Nov 2023 10:03:50 +0000 (UTC) X-FDA: 81463381020.22.822AF0D Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf10.hostedemail.com (Postfix) with ESMTP id 1647FC002B for ; Thu, 16 Nov 2023 10:03:47 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=X9yzwWTA; spf=pass (imf10.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700129028; a=rsa-sha256; cv=none; b=LTstPCINeQkYNE260FeqgP4ksyWhYGwJtT7Ckmixe1ib3PvWQul0nTEN99B0jG/uMEtoOv EeRRq8fFe6P5jvQv6j7BqCETwUgvMmru0UVYw4ldTg1zPUwTIJSn4eU24vmazX7UQKXp9b 9dzq7x1bNcjboOjWllcxJ6siMDdsQPQ= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=X9yzwWTA; spf=pass (imf10.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@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=1700129028; 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=V1E8P5D6YGBbckvW3uechLb8YTWTJOvxSQ0PMr9JKtg=; b=ow6daAr9x/4E1pGkYZoLqLqPsWo2+ZMhWzDlLWgsqJtDUEaKqLiObVQ2sIxoRrOExYfWV+ Jie36dILTSXQZ/hgLx/vMkWJ40SuqbzAkFb2qFliFH4Ehh0S4VghvaBRvq3LH87OwtBo+M giUV6yzOcntV8Agk11xzRODYRluCNuY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700129027; 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:autocrypt:autocrypt; bh=V1E8P5D6YGBbckvW3uechLb8YTWTJOvxSQ0PMr9JKtg=; b=X9yzwWTA5IVTnlsBLjujpOVX13hbgIOzfnG7G7njPRYci0MWTlKAg1rrar8TYn7fd+PcMW uQKDITFogzmV2Td5XBQ+rVW4qVdWxU6KG7dCEVfPexcRuWzly+mdCQt6ChvaXPlSU4a6W0 JDIu2cHPl/Te1/xtrq3yTQiY1NVxmNQ= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-183-YmKA_Ue0NnyylXYxhY6Kow-1; Thu, 16 Nov 2023 05:03:43 -0500 X-MC-Unique: YmKA_Ue0NnyylXYxhY6Kow-1 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-32f8371247fso306776f8f.2 for ; Thu, 16 Nov 2023 02:03:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700129022; x=1700733822; h=content-transfer-encoding:in-reply-to:organization:autocrypt:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=V1E8P5D6YGBbckvW3uechLb8YTWTJOvxSQ0PMr9JKtg=; b=TumZZSREj0c/A26jbQ4AC1LhpDAXd3TLCzmerq2ce9O4/z4irs4+0l3mmPCA4ldbSp ki1O1DUqsiLR3KMFNiSHPJBf26/BR19TDKiGNnCbuscg8tlWDKFVtTdmpPKH6fAJ8gm1 OOLdkcxSCavbSTwN+0J02kuICUOTSq1aoVzHUSzna5rhflTObvo8Rfs6XRLatDQOKj5c XfMTk+mGpdb2UqaS96p+JOeMOduRag+Ef7sLagVELc7KB6jJ+rT15TSRcYt7aKrTt3FD 2bm2XvRFwbdna8MTu8B2Wg/PiV70wS3p4rfxPJRZe09YVLwv1AaV0ZtdxhGWor57LKU3 0nYw== X-Gm-Message-State: AOJu0Yz8sMlkQh/YTnm9Y0XfYEDgCvS6pLcJ8LJPG+R8XrqZRDaGIP7X eoFmmivdrx62oxtoJ7bAYtRTMyRA+Py7SKjfPjUwFRDEYDdY6wOLW821bCDNmVK+4MyBKjOYcFY Ha4fKkxnmvk4= X-Received: by 2002:a05:6000:1acf:b0:32f:dcce:bf38 with SMTP id i15-20020a0560001acf00b0032fdccebf38mr10688787wry.62.1700129022169; Thu, 16 Nov 2023 02:03:42 -0800 (PST) X-Google-Smtp-Source: AGHT+IHWLR/KBAd6o0UkZk02BfBS623zz/kyr4Hi0r/bhw7UPuCXMh4Fvwf++bgWFffaF8vpy2F62w== X-Received: by 2002:a05:6000:1acf:b0:32f:dcce:bf38 with SMTP id i15-20020a0560001acf00b0032fdccebf38mr10688756wry.62.1700129021723; Thu, 16 Nov 2023 02:03:41 -0800 (PST) Received: from ?IPV6:2a09:80c0:192:0:5dac:bf3d:c41:c3e7? ([2a09:80c0:192:0:5dac:bf3d:c41:c3e7]) by smtp.gmail.com with ESMTPSA id l11-20020a5d526b000000b0031c52e81490sm13092355wrc.72.2023.11.16.02.03.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Nov 2023 02:03:41 -0800 (PST) Message-ID: <271f1e98-6217-4b40-bae0-0ac9fe5851cb@redhat.com> Date: Thu, 16 Nov 2023 11:03:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 01/14] mm: Batch-copy PTE ranges during fork() To: Ryan Roberts , Catalin Marinas , Will Deacon , Ard Biesheuvel , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Zenghui Yu , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Andrew Morton , Anshuman Khandual , Matthew Wilcox , Yu Zhao , Mark Rutland , Kefeng Wang , John Hubbard , Zi Yan Cc: linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20231115163018.1303287-1-ryan.roberts@arm.com> <20231115163018.1303287-2-ryan.roberts@arm.com> From: David Hildenbrand Autocrypt: addr=david@redhat.com; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q 9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4 3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs 9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF 89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9 M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3 AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq 3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6 3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8 kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt WNyWQQ== Organization: Red Hat In-Reply-To: <20231115163018.1303287-2-ryan.roberts@arm.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 1647FC002B X-Stat-Signature: y1nn1k9449xtsahwbc9m5aakmejjykiq X-Rspam-User: X-HE-Tag: 1700129027-14010 X-HE-Meta: U2FsdGVkX19F5bVphxCi5lYmb6wtG2Fub0Z3ZMT9g3kcymqDjThlatepBiFyi3Ty3VNwRMpkIB3Y3FfQQUGC2wcr+kgCTbHg9uUaiIjZyYxf2bSkxGRjdRxSbvmTBfpKvQ000JbMqa5laoMan2FZ1tS0isx4aj3p0Z6p3qFTULs9B8mGPpRaKkxlGiAL53QG65hyqxMkcyA5jjVmOoh+hrssX3YzQ5H33IihY8mGlpaow/ciUlKXC5YwpWqCehmTHIAp5wc4Uz4IHlnPEJxzjqdo424mu5rJ9Bc3qwTR5aSJQOeu1fV2JWO9cK+KLz34xcwLIZGRKvmOoOCjGenFbRxK89d6Ch9ts4z9HpsQCeHykkg96a8j04ZUpMYe8BeSqzMfg2D7gdjq8CboA7ouiwh8J2iJp3m/RMt410r/pRRiR3yDTQJ66sqUwI/QHXOpD/L9G780LXWvUZc0Wi9T8zmBkWLUfpmPpTiJyyg44cjrUUZ4qoPeVivCxWvHfo6HbBJMgt6dRmZQKDtVUt5m6YMP65RoS/ZwInooYqWDrI2bTX/YZE+6IC9Z1rLKKFINvpvGInB3uFrJCdVehbPDNwXv5ofIPkl/mY5e4TOLKJ+/V0UIVlUJFxCaZkohqJXDnEj9+W6zOyJ+PoZoSs6x1kekKnPm1mfPo7Cw7I5dguKrGSoVM3EARoD2cQDr44/t5RAr7rc41wG2cWiJPO6xd4CJ2O8tmyZ+36j96mpD3zxg/OAHg8MTa6ue5+SCXDRhOnuKZqEl523IrGVE0WYF3urxbDk5q/R1DfXnx56wOEHiGpUMZPny9Wsosmy9T6QZNh8iRGnNPUMhnfkb8VczmkRaIFcmXQSdvYOVyBN9K8imrPiK5IbqNKzdRcsuqM8pkfS6MNsA662X8TCukVS+vncNw3LbsTKeA34ZT55TyoKSomq6NH3ANSpUjqGX3OgyWlGchSLCfgLNm7Y4Qqu iYClKydC xXfgaIiJQi96tSw0/q5Jj3SWGdVd3KrDb+YMUSCDNvnkReHhlWqV7dNDOlMJPktYBX9YgI9Uzvc69iD/TGWteD+cq83Hin+PTQU5DNjXUGGG8wuUmruCHhblHM1crVjueJm07pmYCAe/nmKfPg9Zd+guyhHFmvwL1QnucegIcDt64W5kI8YuGNrC+pNi6P78Ri+1MOvbgBeYVcbf64Xix10z3XbEyFJCfp6MbGvTMsbzeIZp+PnlmY2YUBpaPGIG96bmtMZmMYTkHw9p71nf+0DE0ycIJEtdWK9keVRwnXJTR8fuCaKsgXsZxqUGzKYMhJshPJGjmYap4ZUYSuyC9NYal+8ihZ2U5E2sCf1nc2ibSRbhqs3fJboUP6t7iHmCgYhY2jHFhM9cGWK8vpqhn6zbVjCgzWah2jQvZ9GGYfXvbHoaOkf5IiQEfDB5y1vplma+tSnFTGqr83mCAhK22KDgo4prpfYjwiitc 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: List-Subscribe: List-Unsubscribe: On 15.11.23 17:30, Ryan Roberts wrote: > Convert copy_pte_range() to copy a set of ptes in a batch. A given batch > maps a physically contiguous block of memory, all belonging to the same > folio, with the same permissions, and for shared mappings, the same > dirty state. This will likely improve performance by a tiny amount due > to batching the folio reference count management and calling set_ptes() > rather than making individual calls to set_pte_at(). > > However, the primary motivation for this change is to reduce the number > of tlb maintenance operations that the arm64 backend has to perform > during fork, as it is about to add transparent support for the > "contiguous bit" in its ptes. By write-protecting the parent using the > new ptep_set_wrprotects() (note the 's' at the end) function, the > backend can avoid having to unfold contig ranges of PTEs, which is > expensive, when all ptes in the range are being write-protected. > Similarly, by using set_ptes() rather than set_pte_at() to set up ptes > in the child, the backend does not need to fold a contiguous range once > they are all populated - they can be initially populated as a contiguous > range in the first place. > > This change addresses the core-mm refactoring only, and introduces > ptep_set_wrprotects() with a default implementation that calls > ptep_set_wrprotect() for each pte in the range. A separate change will > implement ptep_set_wrprotects() in the arm64 backend to realize the > performance improvement as part of the work to enable contpte mappings. > > Signed-off-by: Ryan Roberts > --- > include/linux/pgtable.h | 13 +++ > mm/memory.c | 175 +++++++++++++++++++++++++++++++--------- > 2 files changed, 150 insertions(+), 38 deletions(-) > > diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h > index af7639c3b0a3..1c50f8a0fdde 100644 > --- a/include/linux/pgtable.h > +++ b/include/linux/pgtable.h > @@ -622,6 +622,19 @@ static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addres > } > #endif > > +#ifndef ptep_set_wrprotects > +struct mm_struct; > +static inline void ptep_set_wrprotects(struct mm_struct *mm, > + unsigned long address, pte_t *ptep, > + unsigned int nr) > +{ > + unsigned int i; > + > + for (i = 0; i < nr; i++, address += PAGE_SIZE, ptep++) > + ptep_set_wrprotect(mm, address, ptep); > +} > +#endif > + > /* > * On some architectures hardware does not set page access bit when accessing > * memory page, it is responsibility of software setting this bit. It brings > diff --git a/mm/memory.c b/mm/memory.c > index 1f18ed4a5497..b7c8228883cf 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -921,46 +921,129 @@ copy_present_page(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma > /* Uffd-wp needs to be delivered to dest pte as well */ > pte = pte_mkuffd_wp(pte); > set_pte_at(dst_vma->vm_mm, addr, dst_pte, pte); > - return 0; > + return 1; > +} > + > +static inline unsigned long page_cont_mapped_vaddr(struct page *page, > + struct page *anchor, unsigned long anchor_vaddr) > +{ > + unsigned long offset; > + unsigned long vaddr; > + > + offset = (page_to_pfn(page) - page_to_pfn(anchor)) << PAGE_SHIFT; > + vaddr = anchor_vaddr + offset; > + > + if (anchor > page) { > + if (vaddr > anchor_vaddr) > + return 0; > + } else { > + if (vaddr < anchor_vaddr) > + return ULONG_MAX; > + } > + > + return vaddr; > +} > + > +static int folio_nr_pages_cont_mapped(struct folio *folio, > + struct page *page, pte_t *pte, > + unsigned long addr, unsigned long end, > + pte_t ptent, bool *any_dirty) > +{ > + int floops; > + int i; > + unsigned long pfn; > + pgprot_t prot; > + struct page *folio_end; > + > + if (!folio_test_large(folio)) > + return 1; > + > + folio_end = &folio->page + folio_nr_pages(folio); > + end = min(page_cont_mapped_vaddr(folio_end, page, addr), end); > + floops = (end - addr) >> PAGE_SHIFT; > + pfn = page_to_pfn(page); > + prot = pte_pgprot(pte_mkold(pte_mkclean(ptent))); > + > + *any_dirty = pte_dirty(ptent); > + > + pfn++; > + pte++; > + > + for (i = 1; i < floops; i++) { > + ptent = ptep_get(pte); > + ptent = pte_mkold(pte_mkclean(ptent)); > + > + if (!pte_present(ptent) || pte_pfn(ptent) != pfn || > + pgprot_val(pte_pgprot(ptent)) != pgprot_val(prot)) > + break; > + > + if (pte_dirty(ptent)) > + *any_dirty = true; > + > + pfn++; > + pte++; > + } > + > + return i; > } > > /* > - * Copy one pte. Returns 0 if succeeded, or -EAGAIN if one preallocated page > - * is required to copy this pte. > + * Copy set of contiguous ptes. Returns number of ptes copied if succeeded > + * (always gte 1), or -EAGAIN if one preallocated page is required to copy the > + * first pte. > */ > static inline int > -copy_present_pte(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma, > - pte_t *dst_pte, pte_t *src_pte, unsigned long addr, int *rss, > - struct folio **prealloc) > +copy_present_ptes(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma, > + pte_t *dst_pte, pte_t *src_pte, > + unsigned long addr, unsigned long end, > + int *rss, struct folio **prealloc) > { > struct mm_struct *src_mm = src_vma->vm_mm; > unsigned long vm_flags = src_vma->vm_flags; > pte_t pte = ptep_get(src_pte); > struct page *page; > struct folio *folio; > + int nr = 1; > + bool anon; > + bool any_dirty = pte_dirty(pte); > + int i; > > page = vm_normal_page(src_vma, addr, pte); > - if (page) > + if (page) { > folio = page_folio(page); > - if (page && folio_test_anon(folio)) { > - /* > - * If this page may have been pinned by the parent process, > - * copy the page immediately for the child so that we'll always > - * guarantee the pinned page won't be randomly replaced in the > - * future. > - */ > - folio_get(folio); > - if (unlikely(page_try_dup_anon_rmap(page, false, src_vma))) { > - /* Page may be pinned, we have to copy. */ > - folio_put(folio); > - return copy_present_page(dst_vma, src_vma, dst_pte, src_pte, > - addr, rss, prealloc, page); > + anon = folio_test_anon(folio); > + nr = folio_nr_pages_cont_mapped(folio, page, src_pte, addr, > + end, pte, &any_dirty); > + > + for (i = 0; i < nr; i++, page++) { > + if (anon) { > + /* > + * If this page may have been pinned by the > + * parent process, copy the page immediately for > + * the child so that we'll always guarantee the > + * pinned page won't be randomly replaced in the > + * future. > + */ > + if (unlikely(page_try_dup_anon_rmap( > + page, false, src_vma))) { > + if (i != 0) > + break; > + /* Page may be pinned, we have to copy. */ > + return copy_present_page( > + dst_vma, src_vma, dst_pte, > + src_pte, addr, rss, prealloc, > + page); > + } > + rss[MM_ANONPAGES]++; > + VM_BUG_ON(PageAnonExclusive(page)); > + } else { > + page_dup_file_rmap(page, false); > + rss[mm_counter_file(page)]++; > + } > } > - rss[MM_ANONPAGES]++; > - } else if (page) { > - folio_get(folio); > - page_dup_file_rmap(page, false); > - rss[mm_counter_file(page)]++; > + > + nr = i; > + folio_ref_add(folio, nr); You're changing the order of mapcount vs. refcount increment. Don't. Make sure your refcount >= mapcount. You can do that easily by doing the folio_ref_add(folio, nr) first and then decrementing in case of error accordingly. Errors due to pinned pages are the corner case. I'll note that it will make a lot of sense to have batch variants of page_try_dup_anon_rmap() and page_dup_file_rmap(). Especially, the batch variant of page_try_dup_anon_rmap() would only check once if the folio maybe pinned, and in that case, you can simply drop all references again. So you either have all or no ptes to process, which makes that code easier. But that can be added on top, and I'll happily do that. -- Cheers, David / dhildenb