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 C52422C1581 for ; Mon, 24 Nov 2025 17:38:27 +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=1764005909; cv=pass; b=PXCqpTL7yMgFu+MAxgKCJ1tE1XQ4eV1AU22kHcrYH6m6rQpfThWxulRE1D8XmI95VVijNwUR7MtzDJh4T+HH/ZCmCUzGXsQqn1XiNQsA2lRWWw08Ko0BC4WEJZFxqnk45jvOlLK2YNUrjy9cnGxBwjqF0p7Kibvsav6XJ+NsrtU= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764005909; c=relaxed/simple; bh=FlEOKb4mHqtUiSrQz4rsznhjxCQktsED7xuXJxn0FBQ=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=S7h4aqBMAItRAjT59186p+IqcyG/VelGU24x3KB9W6nVbcSxDJOObYlLZZEGWQECf5Tp+tMlMKAzXl/9aKxLTbVcLEJNGsKaFvkjqM75oyDeG4FVPlU51eAvtvrcXCtCY1I5S2pVEqnmN6t+O0S7OFKYPPinPMLFCKZ3gbAEZ80= 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=lTpppgPt; 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="lTpppgPt" ARC-Seal: i=1; a=rsa-sha256; t=1764005878; cv=none; d=zohomail.com; s=zohoarc; b=e9EMJ7C9V7nfcvE1RkIz5sC1zenMutYXhUVITHZRQIeQwm2t8Lqi234J6GVJS9aFZ7R1yhfKauTyvHWKfH6VG0ozASwZPhIHfgYY58ll59slah96bxdrRLj5Lw0y2QHBNkNw6bg7VQUlFbi+jn2uf7RDgfQp2G8Bb6oZSUXI7kg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1764005878; 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=R8m+NhBlevjY7KyauSa05XI58p+o1dvP2cF9/uZRii4=; b=kwL0cQzMxLZXPtmxyvwPXwNloVKqu5Hx+yuX5Ngv3DT3j5Qr74ZyZ6b5lrExPWimgUR8NUssO90xdzeNejRYWa9bpgxLTNOFHEShiPpmmRbxyzgWFhr5cgPH7ZW3/oaTzeruagG6gbtvetMOhAZIZCJ40qQtmECVWIOFwz3Ufow= 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=1764005878; 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=R8m+NhBlevjY7KyauSa05XI58p+o1dvP2cF9/uZRii4=; b=lTpppgPtFvuHA49IswZAI3ZoKkDDtySWa8cCh4Khbeyp9cMVvV8Rgy6kfAw3hy3L jDA5WF0GpLnrbu6w+LIi/NLkUppOKc+vkZt12i0dR6PfC1Baevf7MRc6s+LszPHdkCU YppXczSVyQ1EDAwCVVhNbllffiE1xPA8/L7FDxxE= Received: by mx.zohomail.com with SMTPS id 1764005875356485.54990985986535; Mon, 24 Nov 2025 09:37:55 -0800 (PST) Message-ID: <7a31f01ac0d63788e5fbac15192c35229e1f980a.camel@mpiricsoftware.com> Subject: Re: [PATCH v2] mm: khugepaged: fix memory leak in collapse_file xas retry loop From: Shardul Bankar To: Matthew Wilcox Cc: linux-mm@kvack.org, dev.jain@arm.com, david@kernel.org, linux-kernel@vger.kernel.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 23:07:46 +0530 In-Reply-To: References: <703387c8908a609c3de966574dfcf481c5a97216.camel@mpiricsoftware.com> <20251124161149.1302507-1-shardul.b@mpiricsoftware.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 On Mon, 2025-11-24 at 16:21 +0000, Matthew Wilcox wrote: >=20 > Then wouldn't freeing the excess node in xas_create_range() be the > correct fix, instead of requiring the caller to think about this? >=20 >=20 Hi Matthew, Thanks for the feedback. Agreed, this is better fixed inside xarray instead of in collapse_file(), so callers don=E2=80=99t need to think about xas_destroy() at all. Looking at the internals, xas_nomem() only allocates a spare node into xas->xa_alloc and xas_alloc() consumes it only if it is required. The only point where we know that the retry loop is truly finished is after xas_create_range() (or xas_create()) succeeds =E2=80=94 at that point, any remaining xa_alloc must be unused. So to align API expectations, I=E2=80=99m trying to understand where you wo= uld prefer to enforce the invariant: - In xas_create_range() after success, ensuring no spare remains? - Or in xas_create(), so that non-range callers benefit as well? Once that API boundary is clear, I can prepare a v3 that moves the fix into lib/xarray.c. Thanks, Shardul