From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 4AD1D1DC985 for ; Tue, 7 Jul 2026 20:21:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783455700; cv=none; b=k8Dx0b3KKWHw0oOnaG+hwbrwjuvrApbIwHEub4KRpsZ/Kk7M6bQE97s04WZNHCz1TKRHm1O4MYsp6PCNVjGzYNsZ71pQi0LI6zljqKnKbVOl3t9FldpG2DOPdxgjV1udSQBPuQBZOjde972llWzMKhUzI32BY6mubj4vTXCIXuE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783455700; c=relaxed/simple; bh=CVtqp35+VE9CRu4ERdqT2aL9jo2dporSFKGL9c3v75M=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=L/2ELAffCf6FWm20UhQ46gAx6ZvNH6NdwgcKvSOEGWqUCyy8C//z+GB+TyiKe1RJs9gzAotXT4a33Wl3QUeeoIlIWKiYbXSst/BJMiWobYMdGMN532q+qzzfG+8WAEVRQ7NmYNKlAK/9KOmV+Orj1Q0873BvjdQhtuPIMX84JW0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=FbaSNUxB; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="FbaSNUxB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A77DA1F000E9; Tue, 7 Jul 2026 20:21:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1783455698; bh=Nh0WAl84rc5RiNO/PWO6pIH/7oEsYwzwMSqG4cyv2M0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=FbaSNUxBzw0hzAhsaB7oAM8R9ROlE84dlL1SDFC8ZZEtmxO5+TRhp7Is1cdfzApsq lHQP6Iiz2tAd8J2aRU12IZMLHuwWnCft3Ddd0sPObJk7DENYXqZMaUNd3INMC53dFU HVUhXOdhXgw0MqF8dhJDW565Yuu4NW/fvxCHGx0k= Date: Tue, 7 Jul 2026 13:21:38 -0700 From: Andrew Morton To: Wupeng Ma Cc: , , , , , Subject: Re: [PATCH] mm/hugetlb: fix missing migratable flag on same-node hugetlb migration Message-Id: <20260707132138.d11a3a759bac55ea5f0f8c22@linux-foundation.org> In-Reply-To: <20260707110254.3147686-1-mawupeng1@huawei.com> References: <20260707110254.3147686-1-mawupeng1@huawei.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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?