From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-97.freemail.mail.aliyun.com (out30-97.freemail.mail.aliyun.com [115.124.30.97]) (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 16B129476 for ; Fri, 20 Dec 2024 02:31:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.97 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734661912; cv=none; b=IWFHxPs+sI+D1SADNbjuDKs5iHN/CF9fDE0HBKvsJKDn4KOWHN3a32QjPgYQV5b9fTgs/J/8gamaeHQY7W1uH2MPkcYl2i07BMUjw68DXstDyrKOKO1I+eLh53EHeArpC8NWT9vjiMb9NJEomlDsJP6rCmq5FT0N1omnKdJ+NYg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734661912; c=relaxed/simple; bh=8OJjh5wsT1HcFOIO4nDj0a4WOmtypRdjcJ2+EddDFY8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=IcgIfrnGOpMN6jQxAy/Pgwt/CY7tErLou0qlL5K/TXCX/8OhBqKhx7lRU16hpBUsMETP+NWBGeZQLSRL9SeWoiA/mYwG9reV7lM4gDOvxRL7AHi9RWGKCI/UmB9wA77kbWzurAhlIX+0nwcesA12kptsHWu2//s9fY9GaCXGVf8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=Jh3OZ0VD; arc=none smtp.client-ip=115.124.30.97 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="Jh3OZ0VD" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1734661901; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=pjgZ1LddfSjIodmv3uycM/tHdI/M/VxL566nKttvgxM=; b=Jh3OZ0VD2Bqqe29IZ7EJDiXuuB1lBIiPri1JCb6yzhTD9FDWjKJmZNvkskT8sbjMnVOKHmQl9Pa5dMXbeqOWCMe6mhdkEKHSXN4IpKqMtXxn9Tjb04vxhAp/kfPVszjQtI2vFECmTiIsB9y5ISZxvsCF9bOpq5koXUoQe10rmcs= Received: from 30.74.144.151(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WLs2SNR_1734661900 cluster:ay36) by smtp.aliyun-inc.com; Fri, 20 Dec 2024 10:31:41 +0800 Message-ID: Date: Fri, 20 Dec 2024 10:31:39 +0800 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: Donet Tom , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Ritesh Harjani , "Aneesh Kumar K . V" , Zi Yan , David Hildenbrand , shuah Khan , Dev Jain References: <20241219124717.4907-1-donettom@linux.ibm.com> From: Baolin Wang In-Reply-To: <20241219124717.4907-1-donettom@linux.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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. 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?