From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.5]) (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 42B232BFC60 for ; Mon, 17 Aug 2026 16:37:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.5 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786984669; cv=none; b=btncu05NTi80cH5ROOJzia7TyaEDrhB80XKM/ldmMY+BwSLtTE4SlOc+fe/5U3aizcL2WOPj0iWqQ15kwPSrme4jG5xLWzhVfKES64MIxCRPmMZr3OI9k5W1rzUnFOi8GKQefwPemhn4rbs+dTLqYTYPJnLrGg6SDbGw0e+g4uM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786984669; c=relaxed/simple; bh=Q+AAaQlCa7JoywNKH+TTUVhCfOU/9+hz51JOd/BSCJY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dJ0ncv/0LRm+lB6fT0QCpWPDXe23q4nA9Ep1HOJ/Tg0uaZHDn7piLnSIUMGsa9xYC5dbAcFW7tfM76O8ajqGj8GOoUxcvsZ2RjiIorPS79AutBSNufu5+y3v9UWztfF5yxurylv0jeAcrkwnp/sRCAuoZpuRN+MpWZdY1DFpH3I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=qH8gdYjc; arc=none smtp.client-ip=220.197.31.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="qH8gdYjc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=pD p7Y6nKu7sVMOaPrZ7lmPO+gASpbZ/ff+zMKWjK5TQ=; b=qH8gdYjcLNS1WpEpSx 64baJWgiOugHZfLBoderdm9quEeiS3SOQVLKa8E9exg1MoHanzXBzgvZYmPwpjji Y8kDZr/vkHyZ70HTFR1DdykbYRmK16inibhvUNwrSZzY9M9LLzAIMeAlxQ2Ab7KV +SBirFLf0BCRL+UshEb8CWA84= Received: from localhost (unknown []) by gzsmtp5 (Coremail) with SMTP id QCgvCgBHJh6dOINqPL8UMw--.63394S2; Tue, 18 Aug 2026 00:36:46 +0800 (CST) From: Hui Su To: akpm@linux-foundation.org Cc: apopple@nvidia.com, balbirs@nvidia.com, byungchul@sk.com, david@kernel.org, gourry@gourry.net, joshua.hahnjy@gmail.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, matthew.brost@intel.com, rakie.kim@sk.com, sh_def@163.com, ying.huang@linux.alibaba.com, ziy@nvidia.com Subject: Re: [PATCH] mm/migrate_device: fix cache flush when replacing huge zero PMD Date: Tue, 18 Aug 2026 00:36:46 +0800 Message-ID: <20260817163646.929678-1-sh_def@163.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260817090640.287a9a415da49e3974797aa4@linux-foundation.org> References: <20260817090640.287a9a415da49e3974797aa4@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:QCgvCgBHJh6dOINqPL8UMw--.63394S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7KFykGr4xKF1xWF15AF43Wrg_yoW8uw4kpr WxGa1Iy397GryUCFn3XFnrJr1Y9ws7ta1fGrn5Jw109398ZFy5KryIgas0gF45Jr48Jr4x Zr4UKa4xZF98Z3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0JUx-BtUUUUU= X-CM-SenderInfo: xvkbvvri6rljoofrz/xtbC6h6wEGqDOJ49GwAA39 > On Mon, 17 Aug 2026 17:35:53 +1000 Balbir Singh wrote: > > > On 8/17/26 4:08 PM, Hui Su wrote: > > > migrate_vma_insert_huge_pmd_page() calls flush_cache_page() before > > > replacing an existing huge zero PMD. However, the third argument to > > > flush_cache_page() is a PFN, while addr + HPAGE_PMD_SIZE is an end > > > virtual address. > > > > > > More importantly, the mapping being invalidated is PMD-sized rather > > > than PAGE_SIZE-sized. Flush the whole PMD range with > > > flush_cache_range(), matching other huge PMD invalidation paths. > > > > > > Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages") > > > Signed-off-by: Hui Su > > > --- > > > mm/migrate_device.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/mm/migrate_device.c b/mm/migrate_device.c > > > index 908d2d4ec43a..098c04c1b124 100644 > > > --- a/mm/migrate_device.c > > > +++ b/mm/migrate_device.c > > > @@ -872,7 +872,7 @@ static int migrate_vma_insert_huge_pmd_page(struct migrate_vma *migrate, > > > > > > if (flush) { > > > pte_free(vma->vm_mm, pgtable); > > > - flush_cache_page(vma, addr, addr + HPAGE_PMD_SIZE); > > > + flush_cache_range(vma, addr, addr + HPAGE_PMD_SIZE); > > > pmdp_invalidate(vma, addr, pmdp); > > > } else { > > > pgtable_trans_huge_deposit(vma->vm_mm, pmdp, pgtable); > > > > Reviewed-by: Balbir Singh > > doh. It's a shame this actually compiled... > > Can we add some speculation about the userspace-visible effects of the > bug? > > I'm assuming we should backport the fix? Hi, I took a closer look at this, there is no userspace-visible effect today. The architectures that currently enable ARCH_ENABLE_THP_MIGRATION use no-op implementations of flush_cache_page()/flush_cache_range(). 32-bit ARM has non-trivial implementations, but does not enable ARCH_ENABLE_THP_MIGRATION. So this appears to be a latent API misuse rather than a currently observable bug, and I don't think a stable backport is necessary. Should I resend a v2 clarifying the userspace-visible effect in the changelog? Thanks, Hui