From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) (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 600C233F7 for ; Tue, 21 Jan 2025 02:17:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.190 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737425873; cv=none; b=iDXz3IXkCfNNeJIBwOblwGY+LB5X1N+9hNu9DQ/xoxmNhJzd36D+S3s8tUnaVaNujD4mmNojTrAhn1nLz9rgEQchA7YjpJ2O2No7wYnpAWuUQ5B5mPo0uZ4JqtvUC5ZYtCDjTzWra7ZuvVfEEvRgadKkcDR+DkgcLlG/0LdelgU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737425873; c=relaxed/simple; bh=fLxiD3x+bWiTZoTNAtUObanYFUVISvxbLnocXCYb+Zo=; h=Message-ID:Date:MIME-Version:CC:Subject:To:References:From: In-Reply-To:Content-Type; b=GUZjySFDlIKGvdOluc52zMBDSM8xeMYwcLi/5qQteGa8MVekOTfSfXSff0/hEZZgoFdEHoa8L/Qi4G1h/T3+amxuhrzdOyrd9KFFdHl6JFT4FjuHLU5mtRjjyo74YhSowpYJhZaHgmDq7iTfgU0MSSMqFfg4dtARFnrWeca6fZY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.190 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.163.44]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4YcW460850z2MWrc; Tue, 21 Jan 2025 10:14:30 +0800 (CST) Received: from kwepemg100017.china.huawei.com (unknown [7.202.181.58]) by mail.maildlp.com (Postfix) with ESMTPS id 7BC631402C4; Tue, 21 Jan 2025 10:17:47 +0800 (CST) Received: from [10.174.178.120] (10.174.178.120) by kwepemg100017.china.huawei.com (7.202.181.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 21 Jan 2025 10:17:46 +0800 Message-ID: <3ebe55f4-99ff-4144-95cc-a8fcf682bc90@huawei.com> Date: Tue, 21 Jan 2025 10:17:45 +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 CC: , , , , , , , Subject: Re: [PATCH v2 3/3] mm: memory-hotplug: check folio ref count first in do_migrate_rang To: References: <20250116061657.227027-1-mawupeng1@huawei.com> <20250116061657.227027-4-mawupeng1@huawei.com> <3b993af4-1fe2-b250-5d07-5840f1ad530d@huawei.com> From: mawupeng In-Reply-To: <3b993af4-1fe2-b250-5d07-5840f1ad530d@huawei.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To kwepemg100017.china.huawei.com (7.202.181.58) On 2025/1/20 14:32, Miaohe Lin wrote: > On 2025/1/16 14:16, Wupeng Ma wrote: >> From: Ma Wupeng >> >> If a folio has an increased reference count, folio_try_get() will acquire >> it, perform necessary operations, and then release it. In the case of a >> poisoned folio without an elevated reference count (which is unlikely for >> memory-failure), folio_try_get() will simply bypass it. >> >> Therefore, relocate the folio_try_get() function, responsible for checking >> and acquiring this reference count at first. >> >> Signed-off-by: Ma Wupeng >> --- >> mm/memory_hotplug.c | 14 ++++---------- >> 1 file changed, 4 insertions(+), 10 deletions(-) >> >> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c >> index 2815bd4ea483..3fb75ee185c6 100644 >> --- a/mm/memory_hotplug.c >> +++ b/mm/memory_hotplug.c >> @@ -1786,6 +1786,9 @@ static void do_migrate_range(unsigned long start_pfn, unsigned long end_pfn) >> page = pfn_to_page(pfn); >> folio = page_folio(page); >> >> + if (!folio_try_get(folio)) >> + continue; >> + >> /* >> * No reference or lock is held on the folio, so it might >> * be modified concurrently (e.g. split). As such, >> @@ -1795,12 +1798,6 @@ static void do_migrate_range(unsigned long start_pfn, unsigned long end_pfn) >> if (folio_test_large(folio)) >> pfn = folio_pfn(folio) + folio_nr_pages(folio) - 1; >> >> - /* >> - * HWPoison pages have elevated reference counts so the migration would >> - * fail on them. It also doesn't make any sense to migrate them in the >> - * first place. Still try to unmap such a page in case it is still mapped >> - * (keep the unmap as the catch all safety net). >> - */ >> if (folio_test_hwpoison(folio) || >> (folio_test_large(folio) && folio_test_has_hwpoisoned(folio))) { >> if (WARN_ON(folio_test_lru(folio))) >> @@ -1811,12 +1808,9 @@ static void do_migrate_range(unsigned long start_pfn, unsigned long end_pfn) >> folio_unlock(folio); >> } >> >> - continue; >> + goto put_folio; >> } >> >> - if (!folio_try_get(folio)) >> - continue; >> - >> if (unlikely(page_folio(page) != folio)) >> goto put_folio; > > Will it be necessary to move this check above folio_test_hwpoison trunk too? Thanks. AFAICT we can do this, I'll move this in the next patch. there is no need to handle this page if the state of this folio changes. > > Thanks. > .