From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 E98672459EA for ; Mon, 24 Nov 2025 10:02:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763978564; cv=none; b=hCaMSU8x7FstZK17ssiIM2auvrDPYEUzVZ+deIksbyDfiPlH7zWVB7UTMJlOS/2m0rGhso0DpeZYunaeZZH0dCFGlK9jkyiU+elghQz1S0RYqzDJ6jMU2JG1OIhDJnE+wsBqxPh1wyVQP0nAU1KU9QZeR3u/XzSe877sGM04Ve4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763978564; c=relaxed/simple; bh=GmXLa82LS7RGCY+Z69mDu9cWNzbwvBxD8DwN1Cgk/BE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=q6fW02EurSt+InRsuzn3WvGBLwgX7ekb06PVpitQsiDWpkOwTUUwhY/AoOD6dDuyVEGWenUXOmV4Z9mJy6o5/SQBe70M+dSEgSFeYF2diKxq7VGjh+jJd+EL3uiW4PTQMhyZpm9yconO+yl9pBBZW3L75zfX/bHw3XvRVAVOSf8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=K8Lh0j1o; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="K8Lh0j1o" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59648C4CEF1; Mon, 24 Nov 2025 10:02:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763978563; bh=GmXLa82LS7RGCY+Z69mDu9cWNzbwvBxD8DwN1Cgk/BE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=K8Lh0j1o8/uaMTI3xC9j01+yv3/Y9danSGOfUKkvgqM9aMx2W2sfy1WbDrFkaGGYK DSZk9q11mVlDbQwIrztwisgnRpdK+6N9SHsbUuNdk1Msgwh7HBtwTNYSetQsGfmfrl pMq1buXF7UDvN0GXvfe7kwEitIvpCaoLGrOALRcoLl/Bv9O9rWTLbJGcc5OWynOntj vWOtNFt3EjdiEjr2nwG7/KrNcbUvh8FZGEyiL0/+p8bGaSTydEc+AcQsGzrdCVyDp9 FCP95ZTPCDK6Gqo6pyP9JaaRGO+KJNAHfT0OfVtpW/c6a7813tNMs4XfVM6n9fW937 4SsIVbHr/3VHw== Message-ID: <36896775-5083-4b3e-9023-949de7722194@kernel.org> Date: Mon, 24 Nov 2025 11:02:35 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: khugepaged: fix memory leak in collapse_file rollback path To: Shardul Bankar , shardulsb08@gmail.com 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, dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev, janak@mpiricsoftware.com References: <20251123132727.3262731-1-shardul.b@mpiricsoftware.com> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: <20251123132727.3262731-1-shardul.b@mpiricsoftware.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/23/25 14:27, Shardul Bankar wrote: > When collapse_file() fails after xas_create_range() succeeds, the > rollback path does not clean up pre-allocated XArray nodes stored in > xas->xa_alloc. These nodes are allocated by xas_nomem() when > xas_create() fails with GFP_NOWAIT and need to be freed. > > The leak occurs because: > 1. xas_create_range() may call xas_nomem() which allocates a node > and stores it in xas->xa_alloc Do you mean that, if xas_create_range() failed, collapse_file() will call xas_nomem() to preallocate memory? I don't immediately see how xas_create_range() would call xas_nomem(). > 2. If the collapse operation fails later, the rollback path jumps > to the 'rollback:' label > 3. The rollback path cleans up folios but does not call xas_destroy() > to free the pre-allocated nodes in xas->xa_alloc Note that after we call xas_nomem(), we retry xas_create_range() -- that previously failed to to -ENOMEM. So the assumption is that the xas_create_range() call would consume that memory. I'm sure there is some corner case where it is not the case (some concurrent action? not sure) > > Fix this by calling xas_destroy(&xas) at the beginning of the rollback > path to free any pre-allocated nodes. This is safe because xas_destroy() > only frees nodes in xas->xa_alloc that were never inserted into the > XArray tree. Shouldn't we just call xas_destroy() in any case, also when everything succeeded? -- Cheers David