From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 40C3A40E8D3 for ; Tue, 28 Jul 2026 10:24:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785234285; cv=none; b=TdMKiR5ty2Ar68NffdjuBN/8Dic/+dO85kjwmDMbPkxalnaOb0hUNcobB/uv1JBrdwfXDbF//CEzaE99Pj+QrE0oadn+DNZv3H0Zt9gnEt5Y9hUPYiPG1n9DotkRF0cIoDwNlJ0KdzXTAL8vX9GiiWHy2+rk/+LL9qdfEY/r47o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785234285; c=relaxed/simple; bh=94E8HRVRTivLOZTA/gFWLgSFoHdq1Rkcfb5c2xXbFvk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Po4MAQRamChGkR6miYdI3H0HlwTOvgWqIe+OFhCwzbLpDWgo2rkqErSQRCRqR4yVFq7buDbcczX0HmyJlaIZW8xRbdZIlEEVNQcUURHQhgrYzC5x2qR3QhJc/gT5In1XUOGSwPjD1lFci2xNtEtIl9tnI3BYu7cRjDXOnQYj+MQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jR/U1JeG; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jR/U1JeG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ADCDC1F01558; Tue, 28 Jul 2026 10:24:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785234283; bh=s4inssPqpsD7BfQ38galVPAMa7N06dym7Nw4RodxwSQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=jR/U1JeGyVQFXc0UcjDexQfbBGIMPfRgB1cDQos5eCRg/8Si/8Frq+oU6W8B73+db sfzNyulYmFX6prEynof0YqjDq+kwjqo4iz3qgXYgRWT1JyDL8yNgmunPeZ81yiEoBr BNDys5Lc5LsL9K26LjuFByF3VqW/UMc4Sf9OtD0VxIMJpfD5cVs1LM29gVret35JZy JXCnoy2lsApajmtZE1JIqGxUE5eDcCSAt8kC0Hv3go/Iy7ar4V4SRaN4HqT51gq2OU sL4H0X0/N/T50h29D3IPTFj4IabNGF1yqywNuEvk8FgLLmZHJhyk4e9HmW6DvM7ibZ /F/3TfW6aopng== Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfauth.phl.internal (Postfix) with ESMTP id D486DF4006B; Tue, 28 Jul 2026 06:24:42 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Tue, 28 Jul 2026 06:24:42 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEyehosGDrX7K3E/QOll5f4laseRKTHb5EXYx6g/CSljkTyK31g3IhRDiB55hhpRD +rj6sLLTD0TAT7a1nJudQaenOaU0Q6jK5rqmvXufpwIYH4DKRCeskDfAKHN3gUBRky2CHN UhSqI4piK7mkQO2R4Aw7x87pfhDwGI73W92J/c1tXRrQe7AffmrnpfU+uu6DJT5c1/E/dT O9lrj1TcFK6FzpMaIbm7xoPsGBMduVWfYzYAgkfOyQ+P9dzAUlUuX0zFB2lZdWSSp8DRmC VV7sqWMMjXGNicieXSixPSHMw2e439xTLDc2pNBjzLhPrfNfnnxK0jfyj7sC40E4PJSpJq NAWSrXzPUDBSPoYFlO6XEhhyqUSe/vFImDBq2g9YLHDhYpzCT5344zpofLOa9dlJ0vDGHs xx5IM/OHQngE6vqpqa3YRLSm2ex7bALcbG3/Lj4eZMr6zIOSM/RQun1RdZJxT7OYb6F9Qy 8SVHdcD/UstGp8BqAbbHKLD30zXcBED8u2VmrAd21BmkFSmUU1sPjunbH3qhz+Lv8HLEnM Q4VggKqr99LxIWHJ79TO1s1Ss2JcDQqCNfXlkRjiUHV63UeUzK5SoorTmND/V6Ezd6kKyE 8aKLdmRP2gCvWF3faEMPNJ0egFJDc9C5pic5o19aFNP12sAu6e1210B5IryQ X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 28 Jul 2026 06:24:42 -0400 (EDT) Date: Tue, 28 Jul 2026 11:24:40 +0100 From: Kiryl Shutsemau To: Hugh Dickins Cc: Andrew Morton , Zi Yan , Kairui Song , Matthew Wilcox , Jan Kara , David Hildenbrand , Chris Arges , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] mm/filemap: __filemap_add_folio() restore index before retrying Message-ID: References: <562fbfa6-dd6d-0b6a-2461-ed2ff1173bc8@google.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <562fbfa6-dd6d-0b6a-2461-ed2ff1173bc8@google.com> On Mon, Jul 27, 2026 at 10:24:14PM -0700, Hugh Dickins wrote: > In __filemap_add_folio()'s split-a-conflict loop, xas_set_order() is > applied repeatedly: each application modifies xas.xa_index, rounding it > down according to the split_order attempted at that stage: and if all > goes as intended, it eventually (or immediately) converges on an > xas_try_split() to the required folio_order, with xas.xa_index now the > same as index: then xas_store() puts the new folio into the xarray there. > > But if a new node was needed, and GFP_NOWAIT allocation did not get one, > the lock is dropped, xas_nomem() used to allocate, and sequence retried. > If (that part of) the xarray is unchanged when the lock is reacquired, > no problem. But what if the conflict was meanwhile resolved by another > thread (perhaps even doing the same thing, inserting a folio at that same > index)? Isn't there a danger of now putting our folio into the xarray at > an intermediate rounded-down index? With !folio_contains() bug to follow, > when CONFIG_DEBUG_VM=y is checking for that. > > Fix this with an xas_set_order() to restore the original xas.xa_index at > the bottom of the loop, so the retry does a full re-evaluation after > reacquiring the lock, and cannot reach xas_store() with the wrong index. > > Production was suffering from rare SIGILLs and SIGSEGVs, executable text > found a page away from where it belonged, !folio_contains() bug hit when > debug enabled: symptoms not seen since this patch went in. > > Fixes: 200a89c159a7 ("mm/filemap: use xas_try_split() in __filemap_add_folio()") > Signed-off-by: Hugh Dickins > Cc: stable@vger.kernel.org Makes sense to me. Acked-by: Kiryl Shutsemau (Meta) -- Kiryl Shutsemau / Kirill A. Shutemov