From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 D48BB18E04D for ; Mon, 23 Dec 2024 12:03:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.156.1 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734955387; cv=none; b=QLQkd5yf2ohkn6PGly0enkMOVQ+UXKN25SL0CpbSxSlCH+xxWdsWbKPh8If9WtMZeeVHBxwHFfD92y6jfx7V6CLwyoZJHjKetbYQaVd5YtOYO2ZUiBUIiS0h/cgWNX2L4GFh21UJbRcfXv/2UsWKbsyVPLh6OE67AAIrSxK9LCM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734955387; c=relaxed/simple; bh=it1w/tUs0NB6Qq//FZjMBxNPS5ETPqJcxxfpgSWuVLs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=YfUvpXaZWJxde8nopi/eM9YoXos4PLrf0tE6ZboWyPqCJPNFR1etGaa3j867l73npJkb003h7U9m3kGIUVzjvgawmULl6zHbsOTGbQLqvi1omQoVvVfw616/Y/EyeIcjPNod+aRww+ssvSf4O2SsKHQBtm/eJ2MyxiaWSO/M9gc= 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=Q2MOZ2Ry; arc=none smtp.client-ip=148.163.156.1 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="Q2MOZ2Ry" Received: from pps.filterd (m0356517.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BN3r2NU020113; Mon, 23 Dec 2024 12:02:47 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=MLRA0p 30L+Wd+5ALFuQw+pXVfJEh6SLA95cewsEpSVM=; b=Q2MOZ2Ry4KKQ/2puvZgBfb SORcGLHqqjqeLqzw6tKCi7NjuPISADhDbrro3M7sQ/7y+IxPPKLGwiSnO04M6Zmk 8ji8z6SX6KI5PNPUt1vdv+fQTOKdpAs8bEX3z9HDBvmPPlWKFB5RSkAWsqq+JsGz Hio2CHmtAilB4c6EUOIbJCHcMEXirfqJnuaiFeV+zQTMHX7B357G2HjNOx8Ve0sn LsLG3oJ6Tt4vFJ49nYxzs81X3hmcPMvN/2cejGZgvlV8rrbuywTq19N7sC2qEob5 mdOT3fFaLFf37ybsQZgnI3l8qAfEBzIKFKFW0wCxJ39Cy0eyr22HC9b+imwDPW6g == Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 43q0bh1x7k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Dec 2024 12:02:46 +0000 (GMT) Received: from m0356517.ppops.net (m0356517.ppops.net [127.0.0.1]) by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 4BNC2kkx021244; Mon, 23 Dec 2024 12:02:46 GMT Received: from ppma22.wdc07v.mail.ibm.com (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 43q0bh1x7e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Dec 2024 12:02:46 +0000 (GMT) Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1]) by ppma22.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 4BNA4hFT020548; Mon, 23 Dec 2024 12:02:44 GMT Received: from smtprelay03.dal12v.mail.ibm.com ([172.16.1.5]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 43p8cy5mm9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Dec 2024 12:02:44 +0000 Received: from smtpav04.wdc07v.mail.ibm.com (smtpav04.wdc07v.mail.ibm.com [10.39.53.231]) by smtprelay03.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 4BNC2hf130933558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Dec 2024 12:02:43 GMT Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 812B858050; Mon, 23 Dec 2024 12:02:43 +0000 (GMT) Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5075F58045; Mon, 23 Dec 2024 12:02:39 +0000 (GMT) Received: from [9.179.4.44] (unknown [9.179.4.44]) by smtpav04.wdc07v.mail.ibm.com (Postfix) with ESMTP; Mon, 23 Dec 2024 12:02:38 +0000 (GMT) Message-ID: <95b7d92f-a12d-47be-9099-f5efebb56ff2@linux.ibm.com> Date: Mon, 23 Dec 2024 17:32:37 +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: Dev Jain , Baolin Wang , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Ritesh Harjani , "Aneesh Kumar K . V" , Zi Yan , David Hildenbrand , shuah Khan References: <20241219124717.4907-1-donettom@linux.ibm.com> <36f9ab13-e057-40a0-8d0b-9939df056fc6@linux.ibm.com> <4d76321e-7905-46e6-8105-f09afde516ff@linux.alibaba.com> Content-Language: en-US From: Donet Tom In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: z7Rq4IdVcds5D16uzkZKbr7-Qb8nGneH X-Proofpoint-GUID: zJz-FekdXfrxyDHLiG7HtaUnAmPevJ8k 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 phishscore=0 lowpriorityscore=0 bulkscore=0 priorityscore=1501 spamscore=0 impostorscore=0 malwarescore=0 adultscore=0 mlxscore=0 clxscore=1015 mlxlogscore=768 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2412230108 On 12/20/24 10:07, Dev Jain wrote: > > On 20/12/24 9:02 am, Baolin Wang wrote: >> >> >> On 2024/12/20 11:12, Donet Tom wrote: >>> >>> On 12/20/24 08:01, Baolin Wang wrote: >>>> >>>> >>>> On 2024/12/19 20: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, >>>> >>>> IMO, I don't think this assumption is correct. At this point, the >>>> TLB entry might also be evicted, so a page fault could still occur. >>>> It's just a matter of probability. >>> In this patch, we mark the page for migration before flushing the TLB. >>> This ensures that if someone accesses the page after the TLB flush, >>> the page fault will occur and in the page fault handler will wait >>> for the >>> migration to complete. So migration will not fail >>> >>> Without this patch, if someone accesses the page after the TLB flush >>> but before it is marked for migration, the migration will fail. >> >> Actually my concern is the same as David's (I did not see David's >> reply before sending my comments), which is that your patch does not >> "rules out all cases". > > > I like this solution but really the proper solution for this one was > to atomically set the migration entry IMHO. > Thank you Dev. I will check and come back on this. > >> >>>> Additionally, IIUC, if another thread is accessing the shmem folio >>>> causing the migration to fail, I think this is expected, and >>>> migration failure is not a vital issue? >>>> >>> In my case, the shmem migration test is always failing, >>> even after retries. Would it be correct to consider this >>> as expected behavior? >> >> IMHO I think your test case is too aggressive and unlikely to occur >> in real-world scenarios. Additionally, as I mentioned, migration >> failure is not a vital issue in the system, and some temporary refcnt >> can also lead to migration failure if you want to create such test >> cases. So personally, I don't think it is worthy doing. > > Agreed, AFAIR the test case starts faulting exactly on those pages > which we want to migrate, making this a very artificial scenario. >