From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 064502594A6 for ; Fri, 20 Dec 2024 02:16:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.158.5 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734661000; cv=none; b=QWWgsYH0+ZgOIZssJ09aTnGbDQeI7Sn27pIupAHjE74ZcYkdjPEAuh5uA5qxqAGt1NsjOJaJOpGaHRRMmGPiYQJibFDtb2Ges4ywjtI786eSmxQIsZ64HN1/26VRppZANOsJ1kTEi8IpbdHUQYDPGlmc63jsYR8xbiItQx7ark4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734661000; c=relaxed/simple; bh=+KXLS8mkfB2+9AzJ9cBi7xd6bpQmh938p97Ielb+X3A=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=PonPYMXNRTGTagGNfqpjUy6dwbUS1kEpcwDZwp9EcrixIEZAlHVM7a50YL8jNnqL+9ds5GXD9MnmOAXy5TedyofUspm6LpeCp884pH/NBm1vqXXm7WUHqH6yy3R4SAkHWwrL0MXLs3OxEdf1SWZTD3uc8q+lkUExogBWSggWBEs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=UGES5jAd; arc=none smtp.client-ip=148.163.158.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="UGES5jAd" Received: from pps.filterd (m0353725.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BK108Yi026671; Fri, 20 Dec 2024 02:16:29 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=pp1; bh=sZWmln 40kCt4oH/1YD56SSyLeoWGH/iTnwRM/Ydg3r4=; b=UGES5jAdd53ljgMY1XJeGE SsTNBiArJLl8UKHYqk+rRfO5tVCaSuadtGOVyrwDF++bMjD9h/EXbuquzeq6cST1 ro3tco8BioVzBNJ3m8ptYyRGklAkjg0RqgzUIxtfuqtHaPrGUqSUG7yMaziMn+7x uD0zJY4jljmMecFhUBqGaYxHbVfI8F1QN4q44HeZnPNMGc0UuKUnrFK/qT87/keO 2+M5Y6bVvZnltZ2jrqGtC9eC/5+76fm6WcPu4FXMOwzCRHbt8uXAR/QOUhihyS/J HJV/y8MtQtKzH2kqxeTba0DADnzIFdLK25gB+P4BD3Dy3fduT6IIEm3SiTmjKGpg == Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 43mmy5aygn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Dec 2024 02:16:29 +0000 (GMT) Received: from m0353725.ppops.net (m0353725.ppops.net [127.0.0.1]) by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 4BK2GSCS020444; Fri, 20 Dec 2024 02:16:28 GMT Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 43mmy5aygj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Dec 2024 02:16:28 +0000 (GMT) Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 4BK1vDlp014451; Fri, 20 Dec 2024 02:16:27 GMT Received: from smtprelay02.dal12v.mail.ibm.com ([172.16.1.4]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 43hq21yr64-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Dec 2024 02:16:27 +0000 Received: from smtpav01.wdc07v.mail.ibm.com (smtpav01.wdc07v.mail.ibm.com [10.39.53.228]) by smtprelay02.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 4BK2GR9I30671462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Dec 2024 02:16:27 GMT Received: from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E85AE5805B; Fri, 20 Dec 2024 02:16:26 +0000 (GMT) Received: from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CFC275804B; Fri, 20 Dec 2024 02:16:22 +0000 (GMT) Received: from [9.179.0.110] (unknown [9.179.0.110]) by smtpav01.wdc07v.mail.ibm.com (Postfix) with ESMTP; Fri, 20 Dec 2024 02:16:22 +0000 (GMT) Message-ID: <4ac9f502-ecdf-440c-9797-a6318c92b882@linux.ibm.com> Date: Fri, 20 Dec 2024 07:46:20 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: migration :shared anonymous migration test is failing To: David Hildenbrand , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Ritesh Harjani , Baolin Wang , "Aneesh Kumar K . V" , Zi Yan , shuah Khan , Dev Jain References: <20241219124717.4907-1-donettom@linux.ibm.com> <3c1665df-9367-4d43-8aa1-6726fbb59640@redhat.com> Content-Language: en-US From: Donet Tom In-Reply-To: <3c1665df-9367-4d43-8aa1-6726fbb59640@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: hQ2FmKd1f69A9Rd1JytScFI91HchQvJa X-Proofpoint-GUID: f_5JfQKTFpIwhNh-gqf4HFh-GW8VPEal X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1051,Hydra:6.0.680,FMLib:17.12.62.30 definitions=2024-10-15_01,2024-10-11_01,2024-09-30_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 phishscore=0 adultscore=0 malwarescore=0 priorityscore=1501 impostorscore=0 clxscore=1015 mlxlogscore=927 spamscore=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2412200015 On 12/19/24 18:25, David Hildenbrand wrote: > On 19.12.24 13:47, Donet Tom wrote: >> The migration selftest is currently failing for shared anonymous >> mappings due to a race condition. >> >> During migration, the source folio's PTE is unmapped by nuking the >> PTE, flushing the TLB,and then marking the page for migration >> (by creating the swap entries). The issue arises when, immediately >> after the PTE is nuked and the TLB is flushed, but before the page >> is marked for migration, another thread accesses the page. This >> triggers a page fault, and the page fault handler invokes >> do_pte_missing() instead of do_swap_page(), as the page is not yet >> marked for migration. >> >> In the fault handling path, do_pte_missing() calls __do_fault() >> ->shmem_fault() -> shmem_get_folio_gfp() -> filemap_get_entry(). >> This eventually calls folio_try_get(), incrementing the reference >> count of the folio undergoing migration. The thread then blocks >> on folio_lock(), as the migration path holds the lock. This >> results in the migration failing in __migrate_folio(), which expects >> the folio's reference count to be 2. However, the reference count is >> incremented by the fault handler, leading to the failure. >> >> The issue arises because, after nuking the PTE and before marking the >> page for migration, the page is accessed. To address this, we have >> updated the logic to first nuke the PTE, then mark the page for >> migration, and only then flush the TLB. With this patch, If the page is >> accessed immediately after nuking the PTE, the TLB entry is still >> valid, so no fault occurs. After marking the page for migration, >> flushing the TLB ensures that the next page fault correctly triggers >> do_swap_page() and waits for the migration to complete. >> > > Does this reproduce with > > commit 536ab838a5b37b6ae3f8d53552560b7c51daeb41 > Author: Dev Jain > Date:   Fri Aug 30 10:46:09 2024 +0530 > >     selftests/mm: relax test to fail after 100 migration failures >         It was recently observed at [1] that during the folio > unmapping stage of >     migration, when the PTEs are cleared, a racing thread faulting on > that >     folio may increase the refcount of the folio, sleep on the folio > lock (the >     migration path has the lock), and migration ultimately fails when >     asserting the actual refcount against the expected.  Thereby, the >     migration selftest fails on shared-anon mappings.  The above > enforces the >     fact that migration is a best-effort service, therefore, it is > wrong to >     fail the test for just a single failure; hence, fail the test > after 100 >     consecutive failures (where 100 is still a subjective choice).  > Note that, >     this has no effect on the execution time of the test since that is >     controlled by a timeout. >         [1] > https://lore.kernel.org/all/20240801081657.1386743-1-dev.jain@arm.com/ > > part of 6.12? > > > As part of that discussion, we discussed alternatives, such as > retrying migration more often internally. > I was trying with this patch and was able to recreate the issue on PowerPC. I tried increasing the retry count, but the test was still failing.