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 1AA1FC3DA64 for ; Thu, 1 Aug 2024 10:07:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 981E36B008A; Thu, 1 Aug 2024 06:07:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 931C96B008C; Thu, 1 Aug 2024 06:07:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 847E86B0092; Thu, 1 Aug 2024 06:07:03 -0400 (EDT) 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 61E4F6B008A for ; Thu, 1 Aug 2024 06:07:03 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 25698A7161 for ; Thu, 1 Aug 2024 10:07:03 +0000 (UTC) X-FDA: 82403248326.02.E133BA8 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf02.hostedemail.com (Postfix) with ESMTP id 5443A8001D for ; Thu, 1 Aug 2024 10:07:01 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf02.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722506779; a=rsa-sha256; cv=none; b=EwHiZXBBr62xklw5CseU+nbAJH4sBn6eLQlsjC6FfHFaUwc1oNvG9HN0c5G1i0PNUWyE3Q ZOktlFkkFLZ8ZrLKLREr2T1PKVZy0eZgi0AA3WikLBBLSvdFMwL5W6e9xE24RQi5Wq23Px eDApwEHqqm+64UlSARRbKtSYwxCMcxM= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf02.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722506779; 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=8pZgoVD1QzcB7udZyiSU90u4k8c/e4SlQ4DfNNU3n6U=; b=kUqJfX6kYKZD13Jo17myt9dx9F4w1uMyfn7TfCIjavIANpgDI0b7sn+DcpZPIGSKGt25K1 Sxr9jF/nx4WMfMTv49/cQsyCPDFbPytMNfBqrkr+b30tvJ0ZD9GHGGoTQstPZsh9QH8qep jyfPw2ZEd1gDP6TCgaLp7UyP1Kj2nfE= 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 2542115A1; Thu, 1 Aug 2024 03:07:26 -0700 (PDT) Received: from [10.1.28.152] (XHFQ2J9959.cambridge.arm.com [10.1.28.152]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B66C63F5A1; Thu, 1 Aug 2024 03:06:56 -0700 (PDT) Message-ID: <738342dc-4a87-4dcc-a515-a9dc085e3186@arm.com> Date: Thu, 1 Aug 2024 11:06:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Race condition observed between page migration and page fault handling on arm64 machines Content-Language: en-GB To: David Hildenbrand , Dev Jain , akpm@linux-foundation.org, willy@infradead.org Cc: anshuman.khandual@arm.com, catalin.marinas@arm.com, cl@gentwo.org, vbabka@suse.cz, mhocko@suse.com, apopple@nvidia.com, osalvador@suse.de, baolin.wang@linux.alibaba.com, dave.hansen@linux.intel.com, will@kernel.org, baohua@kernel.org, ioworker0@gmail.com, gshan@redhat.com, mark.rutland@arm.com, kirill.shutemov@linux.intel.com, hughd@google.com, aneesh.kumar@kernel.org, yang@os.amperecomputing.com, peterx@redhat.com, broonie@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20240801081657.1386743-1-dev.jain@arm.com> <3b82e195-5871-4880-9ce5-d01bb751f471@redhat.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 5443A8001D X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: ibnkusy4cx6arhsb4tmexp9nxznzbyyw X-HE-Tag: 1722506821-747435 X-HE-Meta: U2FsdGVkX19UKN8jyx9v9n5SWk1axuoGG3VFR/i7u0s4ScJpm8CZGB8Ie01Upk5M9rFlRw1LHIdvmY3F+FcxtYg0TkgybL4sNzeIahed0vqLXR83tFkLQ+w/PjKSyYHLzhuXlpXGQ0dPXsOa/0C/ISEjpPK/AK4PtKtJf6UdwtYq3IU66pxD9B2f0Az29pj5LBt5I6yf50Qy43Js6MGpe4wqHejr8zbnwIzzOMP38wCW7glYXdzcErN9YChu5eBEl11hm0JJqmskHL0S06xQi4K/mOF04JudPA5oCgttAb1078sTSWcQF+qsATLxXENAq3LrmAzeVBXeMN4UoKMkSeZvOrYTLNtU3vBtsQc3gEYeJvbLAr+SHlwULVS5VLE4sXPKt9UcwSBe7nKAR0qjezkhlbRB70hRh9qYr6/bUacvPJNhC/Aoq6GpEOK06t+dXFviRO5+rtHOcMwOYB9Ehxwg/Os4lagczASEdM9se6IcaKPY4TUEpjz5q7HOJw5BNbRM0p2Dw4jetW0EfYJl6jAUZh+u+qpjgF5LfzD8BpVzAbLv2h3ucdX/4sDGQccmFFvCBV9itSkiHbJWmYnWmnb8lHZDUILFlp34sam/mahJnJzOSR68nt/u1qfz/ltwbP2A8zzRA6Ixz6fuXuOcLmX2uYrHluEu3RUdftKe8Uuj2xxRsQ4F6Qochexcp8hGy75lm5nRWhtv8Wf89CmO6/QxkHFq35xYLzsSLmqM7Loeb9M1Si+r++XEwDrJDkexT+DDIP1ZJi7Eh8OOq9DR1Sac4tMmkrPSGksfYAil3lCXHovTDJ7V8VAFKXlftpPZkEz59Ik/quW/D/vrPx5M9e3iEo5pl3y+nJJHKFqE/fteasi6ygmDR/FLh0k4TWQ1TwMMTGJuL9lAMPhBmyQ6r+kplhVRq6rKREbaM88mmh8mJi5UPlNgDnDjxtQ3b/j2x4sfCFZd7v7SWmsH9DZ g+a/UGZL MHEYpqiix07qg6wBVHa1Hee2ywVabLFZnzlHp94qibDJEubeZPmjeW7PuV+sZ0WNNkn7SJO/LczhGJ1EEgei+6MsxJQnMDHSwbSb3sSLHDzf9k8PFh81L3FPn3kBHcgBft8+531IP48XOq0KBks/6v0baFH7d4VMv+gfE4+Qe7Vy45Mo= 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 01/08/2024 10:41, David Hildenbrand wrote: > On 01.08.24 11:38, Dev Jain wrote: >> >> On 8/1/24 14:12, David Hildenbrand wrote: >>> On 01.08.24 10:16, Dev Jain wrote: >>>> I and Ryan had a discussion and we thought it would be best to get >>>> feedback >>>> from the community. >>>> >>>> The migration mm selftest currently fails on arm64 for shared anon >>>> mappings, >>>> due to the following race: >>> >>> Do you mean MAP_SHARED|MAP_ANON or MAP_PRIVATE|MAP_ANON_fork? Because >>> you note shmem below, I assume you mean MAP_SHARED|MAP_ANON >> >> >> Yes. >> >>> >>>> >>>> Migration:                        Page fault: >>>> try_to_migrate_one():                    handle_pte_fault(): >>>> 1. Nuke the PTE                        PTE has been deleted => >>>> do_pte_missing() >>>> 2. Mark the PTE for migration                PTE has not been deleted >>>> but is just not "present" => do_swap_page() >>>> >>> >>> In filemap_fault_recheck_pte_none() we recheck under PTL to make sure >>> that a temporary pte_none() really was persistent pte_none() and not a >>> temporary pte_none() under PTL. >>> >>> Should we do something similar in do_fault()? I see that we already do >>> something like that on the "!vma->vm_ops->fault" path. >>> >>> But of course, there is a tradeoff between letting migration >>> (temporarily) fail and grabbing the PTL during page faults. >> >> >> To dampen the tradeoff, we could do this in shmem_fault() instead? But >> then, this would mean that we do this in all >> >> kinds of vma->vm_ops->fault, only when we discover another reference >> count race condition :) Doing this in do_fault() >> >> should solve this once and for all. In fact, do_pte_missing() may call >> do_anonymous_page() or do_fault(), and I just >> >> noticed that the former already checks this using vmf_pte_changed(). > > What I am still missing is why this is (a) arm64 only; and (b) if this is > something we should really worry about. There are other reasons (e.g., > speculative references) why migration could temporarily fail, does it happen > that often that it is really something we have to worry about? The test fails consistently on arm64. It's my rough understanding that it's failing due to migration backing off because the fault handler has raised the ref count? (Dev correct me if I'm wrong). So the real question is, is it a valid test in the first place? Should we just delete the test or do we need to strengthen the kernel's guarrantees around migration success?