From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout05.his.huawei.com (canpmsgout05.his.huawei.com [113.46.200.220]) (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 374513AC0F3 for ; Wed, 8 Jul 2026 01:14:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.220 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783473280; cv=none; b=U+z8Rqq0q7CS7l2BELe+Za0Msu8H39Ms5p/DFcv3CiPFXTVsYsnVv3ejGgNPSLgbRIMYj21+iEVZor0MugNylIoWsYnTlD+bjQTmkrxbUL/70Oh+LaAreT4IFnnAecoxOz7kCGys37d0vG7PEbjWPhea06yYlhq/IYPu6EejCb0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783473280; c=relaxed/simple; bh=bn2idQE2vDnXKvKCVOnyd9egQWhtS5cAi6VACAh9uzs=; h=Message-ID:Date:MIME-Version:CC:Subject:To:References:From: In-Reply-To:Content-Type; b=i6MDxOfrmNow3OjOubnFITpqTySpFR1/wPI0xew7RyhlDJ+HKHvc156kVEmrPSk8LNZ6xKS/9Roy7Ngg3g0rKSmc/1AN63CAJ2Ip/GI5lXfSjPZO7s19aeXJXyJesQrIY3Opqb8d4psaFKzoQFcMMxfhVpC4TZmc4g9JjqVXoJs= 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; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=HyLsUw4S; arc=none smtp.client-ip=113.46.200.220 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="HyLsUw4S" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=ku4PapYckW8dbwQ0G/KnJTyAyuoC7+bOFDK3+GhNzig=; b=HyLsUw4SAyn+5/J+UNKHlyWI/SvXesd1deNMourwRlHUxMnLz0xWEkaXYtx0v0bOXs2V1oTe/ kG/Mzrsyf85a4i2A5wMvEaX1qJcuHq3w0fSQU3tEuFESsxEtD5DIbY5gXcW1ntBcv9S4hQJ3e7K PwpvEMp1gG3CPvf6dkr4T2g= Received: from mail.maildlp.com (unknown [172.19.163.0]) by canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4gw0Jy1CMDz12LHk; Wed, 8 Jul 2026 09:05:54 +0800 (CST) Received: from kwepemj100016.china.huawei.com (unknown [7.202.194.10]) by mail.maildlp.com (Postfix) with ESMTPS id 8AC4340561; Wed, 8 Jul 2026 09:14:33 +0800 (CST) Received: from [10.174.177.15] (10.174.177.15) by kwepemj100016.china.huawei.com (7.202.194.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Wed, 8 Jul 2026 09:14:32 +0800 Message-ID: <7ce07560-3314-4d5a-b81a-14a68b471995@huawei.com> Date: Wed, 8 Jul 2026 09:14:32 +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] mm/hugetlb: fix missing migratable flag on same-node hugetlb migration To: References: <20260707110254.3147686-1-mawupeng1@huawei.com> <20260707132138.d11a3a759bac55ea5f0f8c22@linux-foundation.org> From: mawupeng In-Reply-To: <20260707132138.d11a3a759bac55ea5f0f8c22@linux-foundation.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To kwepemj100016.china.huawei.com (7.202.194.10) On 周三 2026-7-8 04:21, Andrew Morton wrote: > On Tue, 7 Jul 2026 19:02:54 +0800 Wupeng Ma wrote: > >> Commit ba23f58de896 ("mm/migrate: don't call >> folio_putback_active_hugetlb() on dst hugetlb folio") moved setting of >> the migratable flag and active-list placement from >> folio_putback_active_hugetlb(dst) into move_hugetlb_state(), so that >> the freshly allocated destination folio is handled where allocation is >> known to have succeeded. >> >> Unfortunately, the new code was appended after the existing >> temporary-folio block in move_hugetlb_state(), which contains an early >> return added earlier by commit 5af1ab1d24e08 ("mm/hugetlb: optimize >> the surplus state transfer code in move_hugetlb_state()"): >> >> if (folio_test_hugetlb_temporary(new_folio)) { >> ... >> if (new_nid == old_nid) >> return; <-- skips the new code >> ... >> } >> >> /* added by ba23f58 */ >> folio_set_hugetlb_migratable(new_folio); >> list_move_tail(&new_folio->lru, ...&h->hugepage_activelist); >> >> When the destination folio is temporary (i.e. the hugetlb pool was >> exhausted and the migration callback fell back to >> alloc_migrate_hugetlb_folio()) and the migration does not cross a >> node -- the common case, and always true on a single-NUMA system -- >> move_hugetlb_state() returns before setting the migratable flag or >> adding the new folio to the active list. The destination folio is >> then installed in the page table but cannot be isolated afterwards, >> since folio_isolate_hugetlb() rejects folios without the migratable >> flag; a subsequent soft-offline, hard-offline or memory-hotplug >> offline of that folio fails with -EBUSY. >> >> This was reproduced on a single-NUMA arm64 VM: a second >> MADV_SOFT_OFFLINE on an already-migrated hugetlb page returned EBUSY >> and logged "hugepage isolation failed". >> >> Keep the surplus adjustment, which is the only part that depends on >> the node crossing, guarded by `if (new_nid != old_nid)', while making >> the migratable flag and active-list placement unconditional. This >> preserves the cleanup intent of ba23f58 and closes the early-return >> hole. > > Thanks, I'll queue this for test and review. > >> Fixes: ba23f58de896 ("mm/migrate: don't call folio_putback_active_hugetlb() on dst hugetlb folio") > > It sounds like we should backport this into -stable kernels? Yes, it is precisely because this patch was backported to 6.6 stable that we discovered this issue. > >