From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-101.freemail.mail.aliyun.com (out30-101.freemail.mail.aliyun.com [115.124.30.101]) (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 A7B4025F99F for ; Mon, 27 Apr 2026 08:00:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.101 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777276833; cv=none; b=NNSdNwDaERCkFW7mqzynehd86WnesZRh4iL2yyh3GyH5XUF+1BKlptMUpVjkfNFXc11tO6cosmW6t5GUsI1Ao5uYS/oYSjB8OxGwuog6+ZuTlDmnDKybVxpWgJVZLxnV+Vwitg1HrlPWljLw184RCox2laSU1e5cpB86P4ePuMQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777276833; c=relaxed/simple; bh=IWGENiI6slmpHEQNACJKBAf7pn6fqYpnMo7By05kWm8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=PbCcJdrjQwsiNuveOdMmYLU3ix7nCs6tiCH9UiSF/CkPLgvhdTfY4pT47KytqPyjDSZdZyRHbxdbaErWoBVWs6F3dx128kamj7N1Y9LeAq2qjVqMmHM0DMUA0gp8+ScB+4UIOGq2A0r5dcSR0zjf4aMUK4blNFjr742LWSEn+Tw= 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=kTCEDmOA; arc=none smtp.client-ip=115.124.30.101 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="kTCEDmOA" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1777276828; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=E1agXD7b5W0N2QWieFR5z79SW86Ra7sItI1ww9VJ+fA=; b=kTCEDmOABVqsxRbDP83B4Ww804hDcYwUFX2V6xlObQFbCKmE50TNV0QL8TLEBsynukJojLSOB8JsF97mH6tx5CfIipObEDpcuDYQIDtva0KxWRg5vkg6IImu2mKdEQby5+gXavsotnuGteVUDXB/uxSgc01ovGvU4X4DxPISBQ8= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R191e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037026112;MF=ying.huang@linux.alibaba.com;NM=1;PH=DS;RN=12;SR=0;TI=SMTPD_---0X1l4eLU_1777276826; Received: from DESKTOP-5N7EMDA(mailfrom:ying.huang@linux.alibaba.com fp:SMTPD_---0X1l4eLU_1777276826 cluster:ay36) by smtp.aliyun-inc.com; Mon, 27 Apr 2026 16:00:27 +0800 From: "Huang, Ying" To: Sunny Patel Cc: Andrew Morton , David Hildenbrand , Zi Yan , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Alistair Popple , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/migrate_device: fix pgtable leak in migrate_vma_insert_huge_pmd_page In-Reply-To: <20260427063729.17294-1-nueralspacetech@gmail.com> (Sunny Patel's message of "Mon, 27 Apr 2026 12:07:22 +0530") References: <20260427063729.17294-1-nueralspacetech@gmail.com> Date: Mon, 27 Apr 2026 16:00:25 +0800 Message-ID: <87bjf4x27a.fsf@DESKTOP-5N7EMDA> User-Agent: Gnus/5.13 (Gnus v5.13) 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=ascii Sunny Patel writes: > When migrate_vma_insert_huge_pmd_page() jumps to unlock_abort due > to a PMD check failure, the pgtable allocated earlier via > pte_alloc_one() is never freed, causing a memory leak. > > Add a pte_free() call in the unlock_abort error path to release > the pgtable before returning.Also included before goto abort in the > folio check path. > > Signed-off-by: Sunny Patel > --- > > Changes in v2: > - Added pte_free() before goto abort in the folio_is_zone_device() > check path. The lock is not taken at this point so goto unlock_abort would be incorrect here. > - v1 only fixed the unlock_abort path, this version fixes both > leak locations. > > mm/migrate_device.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/mm/migrate_device.c b/mm/migrate_device.c > index fbfe5715f635..7e132196856b 100644 > --- a/mm/migrate_device.c > +++ b/mm/migrate_device.c > @@ -840,6 +840,7 @@ static int migrate_vma_insert_huge_pmd_page(struct migrate_vma *migrate, > } else { > if (folio_is_zone_device(folio) && > !folio_is_device_coherent(folio)) { > + pte_free(vma->vm_mm, pgtable); > goto abort; goto free_abort? > } > entry = folio_mk_pmd(folio, vma->vm_page_prot); > @@ -893,6 +894,7 @@ static int migrate_vma_insert_huge_pmd_page(struct migrate_vma *migrate, > > unlock_abort: > spin_unlock(ptl); free_abort: > + pte_free(vma->vm_mm, pgtable); > abort: > for (i = 0; i < HPAGE_PMD_NR; i++) > src[i] &= ~MIGRATE_PFN_MIGRATE; Although I prefer guard based memory freeing, if we stick with the original error handling, I suggest following existing style more closely. --- Best Regards, Huang, Ying