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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F2E40C54E67 for ; Tue, 26 Mar 2024 17:49:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=WwSUpURpH8Hd2t93YQve/TP3cf6V20i9EmLTbtg/eHQ=; b=cndWQzqENKtgoY xlYE2QWxBsdghDjNQ/w+oJb00m4TtVgkSSjqaRoGB2uEQdv/sSIscDCoX039M7yp8TO41nsoc6hkn c+rs6N5Qx6AQ5qepRrHfRQoAjIvS2UgQyaChPnP8VKrz0JCDpPe2NjU1Mus1XkCzyBd6mxxrvTzVu 3spl1H++agiI68foPkOedfSLK1YPG/4f12pvlzDU+Zgd2k4SnA4swOzADgrVROvAR+/t0Ld/mC7Fi hw/P2jxBbOrBANs1TTnZJSUtgz4CXth0BuqNoT1KdJ5MY0csrm0LsQWo91YuGeqfS7TroZwDxTk0h AVcA2Z7kpySV/Um3MYtg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rpAuw-00000005nx5-1fLp; Tue, 26 Mar 2024 17:48:58 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rpAut-00000005nwM-1w0B for linux-arm-kernel@lists.infradead.org; Tue, 26 Mar 2024 17:48:56 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F39BC2F4; Tue, 26 Mar 2024 10:49:27 -0700 (PDT) Received: from [10.1.29.179] (XHFQ2J9959.cambridge.arm.com [10.1.29.179]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 55DAE3F64C; Tue, 26 Mar 2024 10:48:52 -0700 (PDT) Message-ID: Date: Tue, 26 Mar 2024 17:48:52 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v1 3/4] mm/memory: Use ptep_get_lockless_norecency() for orig_pte Content-Language: en-GB To: David Hildenbrand , Mark Rutland , Catalin Marinas , Will Deacon , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , Andrew Morton , Muchun Song Cc: linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20240215121756.2734131-1-ryan.roberts@arm.com> <20240215121756.2734131-4-ryan.roberts@arm.com> From: Ryan Roberts In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240326_104855_612395_17A58E1E X-CRM114-Status: GOOD ( 25.46 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gMjYvMDMvMjAyNCAxNzozOCwgRGF2aWQgSGlsZGVuYnJhbmQgd3JvdGU6Cj4gT24gMjYuMDMu MjQgMTg6MjcsIFJ5YW4gUm9iZXJ0cyB3cm90ZToKPj4gT24gMjYvMDMvMjAyNCAxNzowMiwgRGF2 aWQgSGlsZGVuYnJhbmQgd3JvdGU6Cj4+PiBPbiAxNS4wMi4yNCAxMzoxNywgUnlhbiBSb2JlcnRz IHdyb3RlOgo+Pj4+IExldCdzIGNvbnZlcnQgaGFuZGxlX3B0ZV9mYXVsdCgpJ3MgdXNlIG9mIHB0 ZXBfZ2V0X2xvY2tsZXNzKCkgdG8KPj4+PiBwdGVwX2dldF9sb2NrbGVzc19ub3JlY2VuY3koKSB0 byBzYXZlIG9yaWdfcHRlLgo+Pj4+Cj4+Pj4gVGhlcmUgYXJlIGEgbnVtYmVyIG9mIHBsYWNlcyB0 aGF0IGZvbGxvdyB0aGlzIG1vZGVsOgo+Pj4+Cj4+Pj4gwqDCoMKgwqDCoCBvcmlnX3B0ZSA9IHB0 ZXBfZ2V0X2xvY2tsZXNzKHB0ZXApCj4+Pj4gwqDCoMKgwqDCoCAuLi4KPj4+PiDCoMKgwqDCoMKg IDxsb2NrPgo+Pj4+IMKgwqDCoMKgwqAgaWYgKCFwdGVfc2FtZShvcmlnX3B0ZSwgcHRlcF9nZXQo cHRlcCkpKQo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIC8vIFJBQ0UhCj4+Pj4gwqDC oMKgwqDCoCAuLi4KPj4+PiDCoMKgwqDCoMKgIDx1bmxvY2s+Cj4+Pj4KPj4+PiBTbyB3ZSBuZWVk IHRvIGJlIGNhcmVmdWwgdG8gY29udmVydCBhbGwgb2YgdGhvc2UgdG8gdXNlCj4+Pj4gcHRlX3Nh bWVfbm9yZWNlbmN5KCkgc28gdGhhdCB0aGUgYWNjZXNzIGFuZCBkaXJ0eSBiaXRzIGFyZSBleGNs dWRlZCBmcm9tCj4+Pj4gdGhlIGNvbXBhcmlzb24uCj4+Pj4KPj4+PiBBZGRpdGlvbmFsbHkgdGhl cmUgYXJlIGEgY291cGxlIG9mIHBsYWNlcyB0aGF0IGdlbnVpbmVseSByZWx5IG9uIHRoZQo+Pj4+ IGFjY2VzcyBhbmQgZGlydHkgYml0cyBvZiBvcmlnX3B0ZSwgYnV0IHdpdGggc29tZSBjYXJlZnVs IHJlZmFjdG9yaW5nLCB3ZQo+Pj4+IGNhbiB1c2UgcHRlcF9nZXQoKSBvbmNlIHdlIGFyZSBob2xk aW5nIHRoZSBsb2NrIHRvIGFjaGlldmUgZXF1aXZhbGVudAo+Pj4+IGxvZ2ljLgo+Pj4KPj4+IFdl IHJlYWxseSBzaG91bGQgZG9jdW1lbnQgdGhhdCBjaGFuZ2VkIGJlaGF2aW9yIHNvbWV3aGVyZSB3 aGVyZSBpdCBjYW4gYmUgZWFzaWx5Cj4+PiBmb3VuZDogdGhhdCBvcmlnX3B0ZSBtaWdodCBoYXZl IGluY29tcGxldGUvc3RhbGUgYWNjZXNzZWQvZGlydHkgaW5mb3JtYXRpb24uCj4+Cj4+IEkgY291 bGQgYWRkIGl0IHRvIHRoZSBvcmlnX3B0ZSBkZWZpbml0aW9uIGluIHRoZSBgc3RydWN0IHZtX2Zh dWx0YD8KPj4KPj4+Cj4+Pgo+Pj4+IEBAIC01MzQzLDcgKzUzNTYsNyBAQCBzdGF0aWMgdm1fZmF1 bHRfdCBoYW5kbGVfcHRlX2ZhdWx0KHN0cnVjdCB2bV9mYXVsdCAqdm1mKQo+Pj4+IMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB2bWYtPmFkZHJl c3MsICZ2bWYtPnB0bCk7Cj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqAgaWYgKHVubGlrZWx5KCF2 bWYtPnB0ZSkpCj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByZXR1cm4gMDsKPj4+ PiAtwqDCoMKgwqDCoMKgwqAgdm1mLT5vcmlnX3B0ZSA9IHB0ZXBfZ2V0X2xvY2tsZXNzKHZtZi0+ cHRlKTsKPj4+PiArwqDCoMKgwqDCoMKgwqAgdm1mLT5vcmlnX3B0ZSA9IHB0ZXBfZ2V0X2xvY2ts ZXNzX25vcmVjZW5jeSh2bWYtPnB0ZSk7Cj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqAgdm1mLT5m bGFncyB8PSBGQVVMVF9GTEFHX09SSUdfUFRFX1ZBTElEOwo+Pj4+Cj4+Pj4gwqDCoMKgwqDCoMKg wqDCoMKgwqAgaWYgKHB0ZV9ub25lKHZtZi0+b3JpZ19wdGUpKSB7Cj4+Pj4gQEAgLTUzNjMsNyAr NTM3Niw3IEBAIHN0YXRpYyB2bV9mYXVsdF90IGhhbmRsZV9wdGVfZmF1bHQoc3RydWN0IHZtX2Zh dWx0ICp2bWYpCj4+Pj4KPj4+PiDCoMKgwqDCoMKgwqAgc3Bpbl9sb2NrKHZtZi0+cHRsKTsKPj4+ PiDCoMKgwqDCoMKgwqAgZW50cnkgPSB2bWYtPm9yaWdfcHRlOwo+Pj4+IC3CoMKgwqAgaWYgKHVu bGlrZWx5KCFwdGVfc2FtZShwdGVwX2dldCh2bWYtPnB0ZSksIGVudHJ5KSkpIHsKPj4+PiArwqDC oMKgIGlmICh1bmxpa2VseSghcHRlX3NhbWVfbm9yZWNlbmN5KHB0ZXBfZ2V0KHZtZi0+cHRlKSwg ZW50cnkpKSkgewo+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgIHVwZGF0ZV9tbXVfdGxiKHZtZi0+ dm1hLCB2bWYtPmFkZHJlc3MsIHZtZi0+cHRlKTsKPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoCBn b3RvIHVubG9jazsKPj4+Cj4+PiBJIHdhcyB3b25kZXJpbmcgYWJvdXQgdGhlIGZvbGxvd2luZzoK Pj4+Cj4+PiBBc3N1bWUgdGhlIFBURSBpcyBub3QgZGlydHkuCj4+Pgo+Pj4gVGhyZWFkIDEgZG9l cwo+Pgo+PiBTb3JyeSBub3Qgc3VyZSB3aGF0IHRocmVhZHMgaGF2ZSB0byBkbyB3aXRoIHRoaXM/ IEhvdyBpcyB0aGUgdm1mIHNoYXJlZCBiZXR3ZWVuCj4+IHRocmVhZHM/IFdoYXQgaGF2ZSBJIG1p c3VuZGVyc3Rvb2QuLi4KPiAKPiBBc3N1bWUgd2UgaGF2ZSBhIEhXIHRoYXQgZG9lcyBub3QgaGF2 ZSBIVy1tYW5hZ2VkIGFjY2Vzcy9kaXJ0eSBiaXRzLiBPbmUgdGhhdAo+IGVuZHMgdXAgdXNpbmcg Z2VuZXJpYyBwdGVwX3NldF9hY2Nlc3NfZmxhZ3MoKS4gQWNjZXNzL2RpcnR5IGJpdHMgYXJlIGFs d2F5cwo+IHVwZGF0ZWQgdW5kZXIgUFQgbG9jay4KPiAKPiBUaGVuLCBpbWFnaW5lIHR3byB0aHJl YWRzLiBPbmUgaXMgdGhlIHRoZSBmYXVsdCBwYXRoIGhlcmUuIGFub3RoZXIgdGhyZWFkCj4gcGVy Zm9ybXMgc29tZSBvdGhlciBtYWdpYyB0aGF0IHNldHMgdGhlIFBURSBkaXJ0eSB1bmRlciBQVEwu Cj4gCj4+Cj4+Pgo+Pj4gdm1mLT5vcmlnX3B0ZSA9IHB0ZXBfZ2V0X2xvY2tsZXNzX25vcmVjZW5j eSh2bWYtPnB0ZSkKPj4+IC8qIG5vdCBkaXJ0eSAqLwo+Pj4KPj4+IC8qIE5vdywgdGhyZWFkIDIg ZW5kcyB1cCBzZXR0aW5nIHRoZSBQVEUgZGlydHkgdW5kZXIgUFQgbG9jay4gKi8KCkFoaCwgdGhp cyBjb21tZW50IGFib3V0IHRocmVhZCAyIGlzIG5vdCByZWZlcnJpbmcgdG8gdGhlIGNvZGUgaW1t ZWRpYXRlbHkgYmVsb3cKaXQuIEl0IGFsbCBtYWtlcyBtdWNoIG1vcmUgc2Vuc2Ugbm93LiA6KQoK Pj4+Cj4+PiBzcGluX2xvY2sodm1mLT5wdGwpOwo+Pj4gZW50cnkgPSB2bWYtPm9yaWdfcHRlOwo+ Pj4gaWYgKHVubGlrZWx5KCFwdGVfc2FtZShwdGVwX2dldCh2bWYtPnB0ZSksIGVudHJ5KSkpIHsK Pj4+IMKgwqDCoMKgwqAuLi4KPj4+IH0KPj4+IC4uLgo+Pj4gZW50cnkgPSBwdGVfbWt5b3VuZyhl bnRyeSk7Cj4+Cj4+IERvIHlvdSBtZWFuIHB0ZV9ta2RpcnR5KCkgaGVyZT8gWW91J3JlIHRhbGtp bmcgYWJvdXQgZGlydHkgZXZlcnl3aGVyZSBlbHNlLgo+IAo+IE5vLCB0aGF0IGlzIGp1c3QgdGhy ZWFkIDEgc2VlaW5nICJvaCwgbm90aGluZyB0byBkbyIgYW5kIHRoZW4gZ29lcyBhaGVhZCBhbmQK PiB1bmNvbmRpdGlvbmFsbHkgZG9lcyB0aGF0IGluIGhhbmRsZV9wdGVfZmF1bHQoKS4KPiAKPj4K Pj4+IGlmIChwdGVwX3NldF9hY2Nlc3NfZmxhZ3Modm1mLT52bWEsIC4uLikKPj4+IC4uLgo+Pj4g cHRlX3VubWFwX3VubG9jayh2bWYtPnB0ZSwgdm1mLT5wdGwpOwo+Pj4KPj4+Cj4+PiBHZW5lcmlj IHB0ZXBfc2V0X2FjY2Vzc19mbGFncygpIHdpbGwgZG8gYW5vdGhlciBwdGVfc2FtZSgpIGNoZWNr IGFuZCByZWFsaXplCj4+PiAiaGV5LCB0aGVyZSB3YXMgYSBjaGFuZ2UhIiBsZXQncyB1cGRhdGUg dGhlIFBURSEKPj4+Cj4+PiBzZXRfcHRlX2F0KHZtYS0+dm1fbW0sIGFkZHJlc3MsIHB0ZXAsIGVu dHJ5KTsKPj4KPj4gVGhpcyBpcyBjYWxsZWQgZnJvbSB0aGUgZ2VuZXJpYyBwdGVwX3NldF9hY2Nl c3NfZmxhZ3MoKSBpbiB5b3VyIGV4YW1wbGUsIHJpZ2h0Pwo+Pgo+IAo+IFllcy4KPiAKPj4+Cj4+ PiB3b3VsZCBvdmVyd3JpdGUgdGhlIGRpcnR5IGJpdCBzZXQgYnkgdGhyZWFkIDIuCj4+Cj4+IEkn bSBub3QgcmVhbGx5IHN1cmUgd2hhdCB5b3UgYXJlIGdldHRpbmcgYXQuLi4gSXMgeW91ciBjb25j ZXJuIHRoYXQgdGhlcmUgaXMgYQo+PiByYWNlIHdoZXJlIHRoZSBwYWdlIGNvdWxkIGJlY29tZSBk aXJ0eSBpbiB0aGUgbWVhbnRpbWUgYW5kIGl0IG5vdyBnZXRzIGxvc3Q/IEkKPj4gdGhpbmsgdGhh dCdzIHdoeSBhcm02NCBvdmVycmlkZXMgcHRlcF9zZXRfYWNjZXNzX2ZsYWdzKCk7IHNpbmNlIHRo ZSBodyBjYW4KPj4gdXBkYXRlIGFjY2Vzcy9kaXJ0eSB3ZSBoYXZlIHRvIGRlYWwgd2l0aCB0aGUg cmFjZXMuCj4gCj4gTXkgY29uY2VybiBpcyB0aGF0IHlvdXIgcGF0Y2ggY2FuIGluIHN1YnRsZSB3 YXlzIGxlYWQgdG8gdXNlIGxvc2luZyBQVEUgZGlydHkKPiBiaXRzIG9uIGFyY2hpdGVjdHVyZXMg dGhhdCBkb24ndCBoYXZlIHRoZSBIVy1tYW5hZ2VkIGRpcnR5IGJpdC4gVGhleSBkbyBleGlzdCA7 KQoKQnV0IEkgdGhpbmsgdGhlIGV4YW1wbGUgeW91IGdpdmUgY2FuIGFscmVhZHkgaGFwcGVuIHRv ZGF5PyBUaHJlYWQgMSByZWFkcwpvcmlnX3B0ZSA9IHB0ZXBfZ2V0X2xvY2tsZXNzKCkuIFNvIHRo YXQncyBhbHJlYWR5IHJhY3ksIGlmIHRocmVhZCAyIGlzIGdvaW5nIHRvCnNldCBkaXJ0eSBqdXN0 IGFmdGVyIHRoZSBnZXQsIHRoZW4gdGhyZWFkIDEgaXMgZ29pbmcgdG8gc2V0IHRoZSBQVEUgYmFj ayB0byAoYQptb2RpZmllZCB2ZXJzaW9uIG9mKSBvcmlnX3B0ZS4gSXNuJ3QgaXQgYWxyZWFkeSBi cm9rZW4/CgoKPiAKPiBBcm02NCBzaG91bGQgYmUgZmluZSBpbiB0aGF0IHJlZ2FyZC4KPiAKClRo ZXJlIGlzIHBsZW50eSBvZiBhcm02NCBIVyB0aGF0IGRvZXNuJ3QgZG8gSFcgYWNjZXNzL2RpcnR5 IHVwZGF0ZS4gQnV0IG91cgpwdGVwX3NldF9hY2Nlc3NfZmxhZ3MoKSBjYW4gYWx3YXlzIGRlYWwg d2l0aCBhIHJhY2luZyB1cGRhdGUsIGV2ZW4gaWYgdGhhdAp1cGRhdGUgb3JpZ2luYXRlcyBmcm9t IFNXLgoKV2h5IGRvIEkgaGF2ZSB0aGUgZmVlbGluZyB5b3UncmUgYWJvdXQgdG8gZXhwbGFpbiAo dmVyeSBwYXRpZW50bHkpIGV4YWN0bHkgd2h5CkknbSB3cm9uZz8uLi4gOikKCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1h aWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xp c3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg== 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 D3121C6FD1F for ; Tue, 26 Mar 2024 17:48:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 64B326B0082; Tue, 26 Mar 2024 13:48:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5FB146B008C; Tue, 26 Mar 2024 13:48:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C2C26B0092; Tue, 26 Mar 2024 13:48:57 -0400 (EDT) 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 3AA726B0082 for ; Tue, 26 Mar 2024 13:48:57 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 072E7A0788 for ; Tue, 26 Mar 2024 17:48:57 +0000 (UTC) X-FDA: 81939925914.14.20C6269 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf10.hostedemail.com (Postfix) with ESMTP id 19EECC0006 for ; Tue, 26 Mar 2024 17:48:54 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711475335; 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; bh=CvpisOiIq20x9lhw6zGo9vMt2Jp7iikVwGfYc3NGP6c=; b=BT94DjZnEsX0r3hwzGJSYlJBaDdopfjxUScK71gIaGxqHWKwvQnHPOunM99sEaHsONDUEP +VISjOs5GopH0wjFCKXUD+lPYe0Sw1vAnBKTpd2iOEqeVWtecx7cQH885k5ux+6rNBi8Lu DaCARScwo3LUlCfJu0O4kov0fJfy5vg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711475335; a=rsa-sha256; cv=none; b=v4Mgl+xMm4kKzygCqQm7nbiTz9UHfSDGcNBk548npz5Iz066cu9Z3Eu+2SvT847WE0VrEy GDzD1xN56tHPiTBmU13XLrikpEaEqMDMyqC4xNTfFzcdA/OLTrSWTU87YCX41qYTxNQkFi mRb+eAxdhrKLsH8b/Fo7AC04K3M0o0M= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F39BC2F4; Tue, 26 Mar 2024 10:49:27 -0700 (PDT) Received: from [10.1.29.179] (XHFQ2J9959.cambridge.arm.com [10.1.29.179]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 55DAE3F64C; Tue, 26 Mar 2024 10:48:52 -0700 (PDT) Message-ID: Date: Tue, 26 Mar 2024 17:48:52 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v1 3/4] mm/memory: Use ptep_get_lockless_norecency() for orig_pte Content-Language: en-GB To: David Hildenbrand , Mark Rutland , Catalin Marinas , Will Deacon , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , Andrew Morton , Muchun Song Cc: linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20240215121756.2734131-1-ryan.roberts@arm.com> <20240215121756.2734131-4-ryan.roberts@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 19EECC0006 X-Rspam-User: X-Stat-Signature: 4xonc69smecz4dc9bj9te8pq5rym7bqq X-Rspamd-Server: rspam03 X-HE-Tag: 1711475334-727879 X-HE-Meta: U2FsdGVkX192vCC142krsVQYmgYP9AogFpP0MphGaTetZQHnF08M1zBZzRqq8v1X1DzZwMeI6veLox9FTWGkM4nO4FptbNJJJwq79qbfS0y5uJ8H6v/TqGTvOBLdhCH0OMWTEOruJ1O+i28WHd4Yfy0+pEqrdLq1nWyMlqOBZKpZs9FO9a1zv/YgwYHIfv9mT2E3kQhgZ+XSXGU23yR6RvM/LLHYC3hqOJaMTRgeXhGxiVTSv+jtl172pgYZsqlsUX0xMIJpU8NvchHlLlynWgwhLwuNtRNyi7D28UfQ6sCqYIml+cnLUSTC/PrEEyArPVY3fD8ILwTW/wwMA9eD1xiXmCnybCzOi5ADo/x3Lg1T5RTqr+fGGhR4l6/JAY1sFXMMl3dn3mlAs5K+WKMPn9GyectRU5ich5ZMkmHYUBdWQLIUB1O4ukt+hEY/VTrhX5tfQIzgfypgiuFosN5n2dg0EqSIx/Ovoljb9ho30aFQ7xHPKkUInqHHVJ3bkfqQIzSo39CW33HjYhi9gfJnG04qItZ5s8Yyuz5FngHFZwCsxBzzPwSRyo/8TtsN1vP40yxCYny9utpemddmtcMwywM4u/8W4m2wRbDV9XffqvldhGknC0muSwuOgAXYKHHbCs+1RgNhloRkaHL5YvXgAS750ZhiKuo/60cIo85DwCrWIb7wMPps3ANdmNU0cXYivB0OwBnXmhLa9KFBDCjuGT7jDgQVFL+rNVd2EyYtlz7lg9FfdSYfc2NHBoKEGbMIQcjQzNs1WnqokEvEUSSFiLn/iWEC49VDMkdLvHpN2aLtsKcPx0e/hP6G3UnnOz9WWNKXBoiuKCNZbQpe0oRKjYDZih/phQo6kb1Vmic8qOvWom2ff6U7PyFSI/dyVRIDy4s+iJ2LImp9ACehBr5LM9Vkrk4ZKG4ve1OTlJnCxqFLgDRE+bBc8jN4UgJ6UKXm2FYMswXZDE6PeOjgOmV u+Ih0JrJ K0S6raRZpPrK+f9iS6zyeRybBqt/4qejj8mQaWX4rlYZ/kzQujYXAHCbjd+zhi1D+zXQdRvaJEAHNzmS778yBe/a7gUGdOT2a9SGrRnLZbHCUQOzdFwFlWtPS7ZhBfYMM05yx0QUQjcUiL4lH8VoDpCvpu3bp/gi8u82adKk4C8vpiUNxsKBeu/yKCfPVyMTirfqFQiUt0ShSD6o8ULpiA0SszvBGObVGcG+z 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 26/03/2024 17:38, David Hildenbrand wrote: > On 26.03.24 18:27, Ryan Roberts wrote: >> On 26/03/2024 17:02, David Hildenbrand wrote: >>> On 15.02.24 13:17, Ryan Roberts wrote: >>>> Let's convert handle_pte_fault()'s use of ptep_get_lockless() to >>>> ptep_get_lockless_norecency() to save orig_pte. >>>> >>>> There are a number of places that follow this model: >>>> >>>>       orig_pte = ptep_get_lockless(ptep) >>>>       ... >>>>       >>>>       if (!pte_same(orig_pte, ptep_get(ptep))) >>>>               // RACE! >>>>       ... >>>>       >>>> >>>> So we need to be careful to convert all of those to use >>>> pte_same_norecency() so that the access and dirty bits are excluded from >>>> the comparison. >>>> >>>> Additionally there are a couple of places that genuinely rely on the >>>> access and dirty bits of orig_pte, but with some careful refactoring, we >>>> can use ptep_get() once we are holding the lock to achieve equivalent >>>> logic. >>> >>> We really should document that changed behavior somewhere where it can be easily >>> found: that orig_pte might have incomplete/stale accessed/dirty information. >> >> I could add it to the orig_pte definition in the `struct vm_fault`? >> >>> >>> >>>> @@ -5343,7 +5356,7 @@ static vm_fault_t handle_pte_fault(struct vm_fault *vmf) >>>>                             vmf->address, &vmf->ptl); >>>>            if (unlikely(!vmf->pte)) >>>>                return 0; >>>> -        vmf->orig_pte = ptep_get_lockless(vmf->pte); >>>> +        vmf->orig_pte = ptep_get_lockless_norecency(vmf->pte); >>>>            vmf->flags |= FAULT_FLAG_ORIG_PTE_VALID; >>>> >>>>            if (pte_none(vmf->orig_pte)) { >>>> @@ -5363,7 +5376,7 @@ static vm_fault_t handle_pte_fault(struct vm_fault *vmf) >>>> >>>>        spin_lock(vmf->ptl); >>>>        entry = vmf->orig_pte; >>>> -    if (unlikely(!pte_same(ptep_get(vmf->pte), entry))) { >>>> +    if (unlikely(!pte_same_norecency(ptep_get(vmf->pte), entry))) { >>>>            update_mmu_tlb(vmf->vma, vmf->address, vmf->pte); >>>>            goto unlock; >>> >>> I was wondering about the following: >>> >>> Assume the PTE is not dirty. >>> >>> Thread 1 does >> >> Sorry not sure what threads have to do with this? How is the vmf shared between >> threads? What have I misunderstood... > > Assume we have a HW that does not have HW-managed access/dirty bits. One that > ends up using generic ptep_set_access_flags(). Access/dirty bits are always > updated under PT lock. > > Then, imagine two threads. One is the the fault path here. another thread > performs some other magic that sets the PTE dirty under PTL. > >> >>> >>> vmf->orig_pte = ptep_get_lockless_norecency(vmf->pte) >>> /* not dirty */ >>> >>> /* Now, thread 2 ends up setting the PTE dirty under PT lock. */ Ahh, this comment about thread 2 is not referring to the code immediately below it. It all makes much more sense now. :) >>> >>> spin_lock(vmf->ptl); >>> entry = vmf->orig_pte; >>> if (unlikely(!pte_same(ptep_get(vmf->pte), entry))) { >>>      ... >>> } >>> ... >>> entry = pte_mkyoung(entry); >> >> Do you mean pte_mkdirty() here? You're talking about dirty everywhere else. > > No, that is just thread 1 seeing "oh, nothing to do" and then goes ahead and > unconditionally does that in handle_pte_fault(). > >> >>> if (ptep_set_access_flags(vmf->vma, ...) >>> ... >>> pte_unmap_unlock(vmf->pte, vmf->ptl); >>> >>> >>> Generic ptep_set_access_flags() will do another pte_same() check and realize >>> "hey, there was a change!" let's update the PTE! >>> >>> set_pte_at(vma->vm_mm, address, ptep, entry); >> >> This is called from the generic ptep_set_access_flags() in your example, right? >> > > Yes. > >>> >>> would overwrite the dirty bit set by thread 2. >> >> I'm not really sure what you are getting at... Is your concern that there is a >> race where the page could become dirty in the meantime and it now gets lost? I >> think that's why arm64 overrides ptep_set_access_flags(); since the hw can >> update access/dirty we have to deal with the races. > > My concern is that your patch can in subtle ways lead to use losing PTE dirty > bits on architectures that don't have the HW-managed dirty bit. They do exist ;) But I think the example you give can already happen today? Thread 1 reads orig_pte = ptep_get_lockless(). So that's already racy, if thread 2 is going to set dirty just after the get, then thread 1 is going to set the PTE back to (a modified version of) orig_pte. Isn't it already broken? > > Arm64 should be fine in that regard. > There is plenty of arm64 HW that doesn't do HW access/dirty update. But our ptep_set_access_flags() can always deal with a racing update, even if that update originates from SW. Why do I have the feeling you're about to explain (very patiently) exactly why I'm wrong?... :)