From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sender3-of-o52.zoho.com (sender3-of-o52.zoho.com [136.143.184.52]) (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 A6CE2314B6A for ; Mon, 24 Nov 2025 15:24:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.184.52 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763997890; cv=pass; b=ODDpwX/sjRydCBQIf9O5Hvk61+aZjqKYhYHx1KLG402hfV8u9tYmPkTGXqDh/cEz0p4dtTAoECAoXZ4W77mGsQNJDrVX2LVqep3pSKFmUMa2cvcN4QBe426jfzd0uxot/p2smNxee5HOW7Wqr/4JinHTJotP7cXdigcnNJC+UR4= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763997890; c=relaxed/simple; bh=b//E1GPtfU5B6FYfiGToqE3Z1Qg68+Vhzf25DfB+tHs=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=JybAQnlgtaqlS0WKqh4/J1GfJIjgqb0zfXwbsHZ/0barczK2szKq+tvGENj1or3FRv7lqSfvPww5dy2YQmTCndSm0DGgzi6ieCwDf3KJOK1FavjHDp24uy25/gBsVkPnmJTzn8kGCZiteqH6GUGgP2MYWxA6mgn/JyJwLQkHutM= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=mpiricsoftware.com; spf=pass smtp.mailfrom=mpiricsoftware.com; dkim=pass (1024-bit key) header.d=mpiricsoftware.com header.i=shardul.b@mpiricsoftware.com header.b=g7i8o4iN; arc=pass smtp.client-ip=136.143.184.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=mpiricsoftware.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mpiricsoftware.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=mpiricsoftware.com header.i=shardul.b@mpiricsoftware.com header.b="g7i8o4iN" ARC-Seal: i=1; a=rsa-sha256; t=1763997854; cv=none; d=zohomail.com; s=zohoarc; b=EBeJp5vovdKkETGoO/PoGM6fQch/V3O3FTzb7HeNuEJc3nbfaY/3s0w7ZeKqYUMQOzJI0wpjzJi2NP0sELcjqjmQbwAVzbKGGmIOYyoUI2toNiBl5CTCArY1plSD2qDURzTDfNb49bQG2JXHYhecjnqI2IY0utLmLbBXTxH+xXo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1763997854; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=JEXtvNdRE9uegVpdOCTTCGjA7xnKIaXPCGqm5liMLPU=; b=DnKLykFjNgOQ0bm/xguwrAhqelgGOmZZcFd2KNp+8tT+Eo4Ld8meUh51pUci/k73U9dth5gh2gb/emFrhGM3Y+ESWG+bhncCDc4i71tpib1KPFKVU3QYDm2KHog512iCVjmF6LpAT1Gtgla6LeXbAr5mzvmypuax5hkiCYIaAqg= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=mpiricsoftware.com; spf=pass smtp.mailfrom=shardul.b@mpiricsoftware.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1763997854; s=mpiric; d=mpiricsoftware.com; i=shardul.b@mpiricsoftware.com; h=Message-ID:Subject:Subject:From:From:To:To:Cc:Cc:Date:Date:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:MIME-Version:Message-Id:Reply-To; bh=JEXtvNdRE9uegVpdOCTTCGjA7xnKIaXPCGqm5liMLPU=; b=g7i8o4iN2PFgR7mQtXvwdnLUJH2EFf50k6NSt0hhN7/g0AeK6EeFu0AomQlCPz0N vL/5QpyARyjDO8VKMaotluKYUkydi9f9Cw+PYCKxpGHbuP9yVVv/U6Vg7maKus/+RfQ IP5uf+OenlrehLjJ58dxExAr6z4zBIkJp5fTfQfk= Received: by mx.zohomail.com with SMTPS id 1763997851456767.0702426220278; Mon, 24 Nov 2025 07:24:11 -0800 (PST) Message-ID: <703387c8908a609c3de966574dfcf481c5a97216.camel@mpiricsoftware.com> Subject: Re: [PATCH] mm: khugepaged: fix memory leak in collapse_file rollback path From: Shardul Bankar To: Dev Jain , "David Hildenbrand (Red Hat)" Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com, akpm@linux-foundation.org, lorenzo.stoakes@oracle.com, ziy@nvidia.com, baolin.wang@linux.alibaba.com, Liam.Howlett@oracle.com, npache@redhat.com, ryan.roberts@arm.com, baohua@kernel.org, lance.yang@linux.dev, janak@mpiricsoftware.com, shardulsb08@gmail.com Date: Mon, 24 Nov 2025 20:53:54 +0530 In-Reply-To: <9d4774ec-41d4-4c6f-899a-991187e58897@arm.com> References: <20251123132727.3262731-1-shardul.b@mpiricsoftware.com> <36896775-5083-4b3e-9023-949de7722194@kernel.org> <9d4774ec-41d4-4c6f-899a-991187e58897@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ZohoMailClient: External Hi David, Dev, Thanks for the clarification, that really helped straighten things out. On Mon, 2025-11-24 at 17:16 +0530, Dev Jain wrote: >=20 > On 24/11/25 3:32 pm, David Hildenbrand (Red Hat) wrote: > >=20 > > =C2=A0Do you mean that, if xas_create_range() failed, collapse_file() > > will call xas_nomem() to preallocate memory?=20 Yes that's correct. > > =C2=A0I don't immediately see how xas_create_range() would call > > xas_nomem().=20 xas_create_range() indeed doesn't call xas_nomem() internally. The control flow is: xas_create_range(&xas) -> xas_create() -> may set XA_ERROR(-ENOMEM) collapse_file() detects xas_error() -> calls xas_nomem() -> allocates a spare node and stores it in xas->xa_alloc > >=20 > > =C2=A0Note that after we call xas_nomem(), we retry xas_create_range() = - > > - that previously failed to to -ENOMEM.=20 > >=20 > > =C2=A0So the assumption is that the xas_create_range() call would > > consume that memory.=20 > >=20 > > =C2=A0I'm sure there is some corner case where it is not the case (some > > concurrent action? not sure)=C2=A0 > =C2=A0 > Someone else can put slots in the xarray since we dropped the lock. I > cannot prove this, but surely > disproving this is harder : ) As Dev pointed out, after xas_nomem(), another thread may expand the xarray while the lock is dropped. In that case, the next xas_create_range() retry could succeed without consuming xa_alloc, so xas_destroy() should clear the unused spare node. Calling xas_destroy() on all exit paths therefore seems correct and safe. > > =C2=A0Shouldn't we just call xas_destroy() in any case, also when > > everything succeeded?=C2=A0 > =C2=A0 > Yeah you are right. We should probably do > diff --git a/mm/khugepaged.c b/mm/khugepaged.c > index abe54f0043c7..0794a99c807f100644 > --- a/mm/khugepaged.c > +++ b/mm/khugepaged.c > @@ -1872,11 +1872,14 @@ staticintcollapse_file(struct mm_struct *mm, > unsignedlongaddr, > do { > xas_lock_irq(&xas); > xas_create_range(&xas); > - if (!xas_error(&xas)) > + if (!xas_error(&xas)) { > + xas_destroy(&xas); > break; > + } > xas_unlock_irq(&xas); > if (!xas_nomem(&xas, GFP_KERNEL)) { > =C2=A0result =3D SCAN_FAIL; > + xas_destroy(&xas); > goto rollback; > =C2=A0} > =C2=A0} while (1); I=E2=80=99ll prepare v2 implementing Dev=E2=80=99s suggestion and update th= e commit message accordingly. Thanks and Regards, Shardul