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 727BED32D96 for ; Tue, 12 Nov 2024 11:28:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE0978D0002; Tue, 12 Nov 2024 06:28:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E8F038D0001; Tue, 12 Nov 2024 06:28:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D2F978D0002; Tue, 12 Nov 2024 06:28:21 -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 B4DCB8D0001 for ; Tue, 12 Nov 2024 06:28:21 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 585051C764A for ; Tue, 12 Nov 2024 11:28:21 +0000 (UTC) X-FDA: 82777218006.06.63042F3 Received: from mail.marcansoft.com (marcansoft.com [212.63.210.85]) by imf21.hostedemail.com (Postfix) with ESMTP id 42DE11C0013 for ; Tue, 12 Nov 2024 11:26:59 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=asahilina.net header.s=default header.b=aQZUj9n9; dmarc=pass (policy=quarantine) header.from=asahilina.net; spf=pass (imf21.hostedemail.com: domain of lina@asahilina.net designates 212.63.210.85 as permitted sender) smtp.mailfrom=lina@asahilina.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731410837; a=rsa-sha256; cv=none; b=YGtQ6DkLn5skByPn3F2K5WOY66aoMQWKjYoOGXvHAXIwsiK8cWC3remVmQTNOv8dnK7EOF qsig1eqfFw+XYaK4uB8CDhJtO08mJCGfc3nVb9QFMLCTaz0h+BD7J1ou6n/g41RsDga2Ta wdlhjubjTPtcTuRJPw6FubpOkGrjgGY= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=asahilina.net header.s=default header.b=aQZUj9n9; dmarc=pass (policy=quarantine) header.from=asahilina.net; spf=pass (imf21.hostedemail.com: domain of lina@asahilina.net designates 212.63.210.85 as permitted sender) smtp.mailfrom=lina@asahilina.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731410837; 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=dEh5bG1HKmWVGnOTZVlzVG4q8Ygtjqp0tJWe2iqVB6w=; b=BtD7jd+p2C+/GJq1gvY6L4dLyzyT080IZHKrz086/29WpBA85DPVFKbVL+iUZ6vvf8lLNk rU/UZOdA4LEdAPpYeJPqba2JLD1y6NsFwd0EBQPWNAeohQ2m4xTpShqcCGH9BPTmf/NtOe wogczgQT7hQY7OLbatc4ONjA8aBOs+U= Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: lina@asahilina.net) by mail.marcansoft.com (Postfix) with ESMTPSA id E9DC741F4A; Tue, 12 Nov 2024 11:28:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=asahilina.net; s=default; t=1731410895; bh=qvVC5S1lMfYGMt3SGwT/Cfc8QpLCdcFWKTOkeSrlUmQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=aQZUj9n9OUMWu43r9D/leB3Y2fi2fV3QlOQgBqKo33YFuUI/tHDCNdJgRnJEU4F/V e0w3YlehUoYGsA4PdGH0bP05q6VSOp3N9WQ1DYxg2BXz79kjxK3/JSA0LlOlLWKH6u wXRXTlIgOSMuXQNUh6HeehcCXR/AvZ+QZ+2P75ygR07+ncUWAaYbUwOHVZ2xc+Z8Al WdqFfGzRVbn5UbZM0ob0E50wm3ZyX7n3Ft5BtXMCQmwKgbvLd2YsxqWHS4MjL5jm2Y r7SRztYNelCK/wlfunlOXiuOsSY8CAW5MwKDxuADnu7KVZch/Hqoss5afDbXC5iEqg Tqz2ZmKEMJmPQ== Message-ID: Date: Tue, 12 Nov 2024 20:28:13 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: Fix __wp_page_copy_user fallback path for remote mm To: David Hildenbrand , Alistair Popple Cc: Andrew Morton , Sergio Lopez Pascual , linux-mm@kvack.org, linux-kernel@vger.kernel.org, asahi@lists.linux.dev, Dan Williams References: <20241101-mm-remote-pfn-v1-1-080b609270b7@asahilina.net> <2d8380b9-3d03-4263-b5bf-7e0227c83ba9@asahilina.net> <0977a33b-8318-43a5-a5a1-4eb8c93ca270@redhat.com> <64d386e8-6684-4213-8aba-7d1daf94f2cf@asahilina.net> <412298ff-80bc-4111-8c72-29a5263a5d32@redhat.com> <87ttceu0i8.fsf@nvdebian.thelocal> <821d15f9-233e-4b9d-8194-5de1835113c7@asahilina.net> <50578e9d-6562-4f0f-af7c-cabfb875bbb7@redhat.com> Content-Language: en-US From: Asahi Lina In-Reply-To: <50578e9d-6562-4f0f-af7c-cabfb875bbb7@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 42DE11C0013 X-Rspamd-Server: rspam01 X-Stat-Signature: 6ufs7zk7cfuqr9ora4hw6r3osodoekc5 X-HE-Tag: 1731410819-202943 X-HE-Meta: U2FsdGVkX18RUnq/cjuNWZNmnNIKEZ7phsUlPQVb0kuTVc1BWEQyhilOQ4a3ahftluvRBFVV/ddprQ78XXTN3kOzWWJEIg+CtHR5p/i7fU3M/fJrsGo7lj+Uu0LAoYW7SIcgppz0JSlClPEoXpVRCYRFmseVcpKgi8IZNqyGYlv2TJYSQPT8xkqTO17cinZ6K9sV7TVkbLb0iCyQB7zD0gMUxHJakgALqRsvhwJ7zXjQ3QHkiBrEh3RDT+A7O731OVTRcPFagPsGW+Qnt/cA+dShFdxdcsiLpmsp03Suvxz5zEGSFWpovu+tadj3aYyn665Ur4HXLM7Cw22XXGaJf7+kAOtTkRYyfW2U3H002LMUsASXStS/OodFzXO6eTXXaS2XIHaM6lBT+EfItIAkrq/GeVRhi957NHhc/V1hBpAr0jddx677jRgV/cIn/XfLNUD9VWhjmLkHlc25oXNHiYFA1ndE8kDuDmuXtjhF9jqmkcOr4/MnVq3M0u15K4FczpcjkFupJb3ZHRVoS10QVikV89IKLORZkNvbT+n1FeRpiCJxPABoxit1QZvhC8e4tAMKoJ+sciuM3W9XfLtvuc4FPwZBfOXOkGGWmut9Ua6hgNNUg0QfZoBgduU1tra1CFsSN2GM6nEa+gSXaTXQPgHwUvqsBOxRS6Y2JhkMNuGE1TXe/wL0MXYaZtM11Yt1LG9gpNAz2Gcl8e5duwHVK2CwYg+7c1Ndyw9M5aQrHXu96G6ZH+703W3xVBODGyOQtvnTDWHhShbVt6ZZShVOI0tyoHa00kRR9Jr66iH6YdbiSnHpWHSGfsabGM8bf5wowe59XisBWZDZ4u1agdvdeIbtba/AIak8hy+eo2fLn/gzDg/qfqZQLey1r7sD8MWeL8NW/E1ijjaqkRZxJhCb+26Iq81GiCINEqz6FIJ5nYri00rrH3F8d9TQmBRubTRh0LhqC0TAk9R4CDtk2XC ENqBXFwi MqT4yJbksfH6A1dpomzGXOoYRNg5nu6ghjvYyD7Ado3hDq18+tjyUp5y8mBJmquzlcLngolvz6A74W3GCHnUS4qZD5wOcKHzT0G7WJnKiV15YgKX3fnFqt3IlwEAJMVRmAhQvxkNiplWZ8Tok5nYSZ+chVysnoyIrDdXX35YpKIuQvbo5n93n3YlZoNZaqYYO+HduXHI4aHhx3FeVajV57P8zb3by33Rgk1p61cegW8Wv++zBdSpPGsyyZpHlheu42dzzoIBlur+COSIi69AbhhyF0nM4sW0t2EdsXghK1R730apxKWuEw5vuerz/3NCrkMnf1IRnBUPlk0gsCNY4AqX0g0IVNbXJYcnDalMVjtFNnJQ/6BaAIhwFsw== 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 11/12/24 7:00 PM, David Hildenbrand wrote: > On 12.11.24 10:48, Asahi Lina wrote: >> >> >> On 11/11/24 8:24 AM, Alistair Popple wrote: >>> >>> David Hildenbrand writes: >>> >>>> On 07.11.24 18:32, Asahi Lina wrote: >>>>> On 11/8/24 2:14 AM, David Hildenbrand wrote: >>>>>> I recall that there is still a problem with false-positives on >>>>>> folio_test_anon() with ZONE_DEVICE pages, so it's maybe not that >>>>>> easy ... and the whole get_dev_pagemap() stuff is nasty. >>> >>> Specifically FS DAX reuses PAGE_MAPPING_ANON in >>> include/linux/page-flags.h >>> >>>      /* >>>       * Different with flags above, this flag is used only for fsdax >>> mode.  It >>>       * indicates that this page->mapping is now under reflink case. >>>       */ >>>      #define PAGE_MAPPING_DAX_SHARED    ((void *)0x1) >>> >>> FS DAX pages are never anon though, so you could probably test for >>> !vma_is_dax() and/or add an implementation of is_fsdax_page(). >>> >>>>>> Likely we would have to do what GUP does, and temporarily grab a >>>>>> pgmap >>>>>> reference. Gah. >>>>>> >>>>>> >>>>>> So if we sort out the pagemap stuff and the possibly wrong >>>>>> folio_test_anon() on some ZONE_DEVICE pages (but not all, because >>>>>> IIRC >>>>>> DEVICE_PRIVATE can be anon ...), it might be doable. >>> >>> Correct, DEVICE_PRIVATE and DEVICE_COHERENT pages are always anon (at >>> least for now). >>> >>>>>> But it sounds ugly, especially because that code might change soon >>>>>> and >>>>>> not require messing with ZONE_DEVICE pages on that level. >>> >>> Yes, I'm hopoing to get the next version of that series posted this >>> week. I found a couple of other FS DAX bugs that slowed me down. >>> >>>   - Alistair >>> >>>>>> And then, we'd not be able to handle VM_PFNMAP cleanly ... >>>>>> >> >> If this is all going to be fixed another way soon then I think there's >> no rush to get a workaround in earlier than that, I just don't want it >> to fall by the wayside. >> >> We have my original patch downstream in libkrunfw (which despite the >> lockdep complaints does work in practice) > > I assume it's sufficient to deadlock when a writer pops up after you > succeeded with the first read-locking, and before you start the second > read-locking. IIRC, rwsem is a fair lock, so read-locking when already- > read-locked is not guaranteed to work. > > That's why lockdep complains. > That's fair, I just mean that "works most of the time" is probably good enough for the time being considering that this codepath is only invoked by debuggers in practice anyway. ~~ Lina