From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-178.mta0.migadu.com (out-178.mta0.migadu.com [91.218.175.178]) (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 1C1113BA23F for ; Mon, 2 Mar 2026 15:11:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772464314; cv=none; b=ClwyP7R3G+DQnAzg692weH15XoP1NjwFQcNPd6PG8GW2s2szne3MteOYz3QOO8UOMzauDKuHK85x2Ax8B1ow2CGUe/u1C1WoA0e5tMiQrBzQZq5/4DG/LcfvskSrKLKZqy4gyYlVUxJ1/dttWI9/LjmHLihde2hS++kpg3Ab6IM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772464314; c=relaxed/simple; bh=KCBtXYwww92nUUG2zAgJgef7ktaJj2c3DTMGMJdUk1g=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=s5d37cn+/odsbkBmvvgUlf/StQ9ZIXecdoxbQYJZ4ZrvoAV4V1Qir0nWuOnf4OBhOF2+MSli0+sRaAcoOsJTCtDHsH7sqGo14XNPitGixdrFEJsTKd1JyjJzEDcU9aUohGatp85Q7irQS/mru0tWzM1Et5HndlpfwYJJsctSj6s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=oT5+jyWw; arc=none smtp.client-ip=91.218.175.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="oT5+jyWw" Message-ID: <6a568d3c-daf3-46ba-a3ce-0a0deca824c2@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1772464301; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jXXw9BNPUOHdywM1sGGDpV4CuKnSXirRfOqdKTWATAU=; b=oT5+jyWwG/YxILKJmwFoom9NuVkMPFACb21bQYP02+BuJNutRR82NYY4ImmIDBhgFQ/5gR sfpjsJtrYJFEB8GJg9Fx1BbwjJqXGIgL+gQPoU7+5lJI75HtJA2X/KGCd0sgCBDh2FnPzG hZGcZvbRoFHZQzg6m6SI1Dz7B6yg2fE= Date: Mon, 2 Mar 2026 23:11:27 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH] mm/huge_memory: fix a folio_split() race condition with folio_try_get() To: "David Hildenbrand (Arm)" , Zi Yan , Andrew Morton Cc: Lorenzo Stoakes , Hugh Dickins , Baolin Wang , "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Matthew Wilcox , Bas van Dijk , Eero Kelly , Andrew Battat , Adam Bratschi-Kaye , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, stable@vger.kernel.org References: <20260228010614.2536430-1-ziy@nvidia.com> <64fa6a73-8952-4ee1-b7c3-8b0ebef3ea78@kernel.org> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Lance Yang In-Reply-To: <64fa6a73-8952-4ee1-b7c3-8b0ebef3ea78@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 2026/3/2 22:28, David Hildenbrand (Arm) wrote: > On 2/28/26 04:10, Lance Yang wrote: >> >> >> On 2026/2/28 09:06, Zi Yan wrote: >>> During a pagecache folio split, the values in the related xarray >>> should not >>> be changed from the original folio at xarray split time until all >>> after-split folios are well formed and stored in the xarray. Current use >>> of xas_try_split() in __split_unmapped_folio() lets some after-split >>> folios >>> show up at wrong indices in the xarray. When these misplaced after-split >>> folios are unfrozen, before correct folios are stored via >>> __xa_store(), and >>> grabbed by folio_try_get(), they are returned to userspace at wrong file >>> indices, causing data corruption. >>> >>> Fix it by using the original folio in xas_try_split() calls, so that >>> folio_try_get() can get the right after-split folios after the original >>> folio is unfrozen. >>> >>> Uniform split, split_huge_page*(), is not affected, since it uses >>> xas_split_alloc() and xas_split() only once and stores the original folio >>> in the xarray. >>> >>> Fixes below points to the commit introduces the code, but >>> folio_split() is >>> used in a later commit 7460b470a131f ("mm/truncate: use folio_split() in >>> truncate operation"). >>> >>> Fixes: 00527733d0dc8 ("mm/huge_memory: add two new (not yet used) >>> functions for folio_split()") >>> Reported-by: Bas van Dijk >>> Closes: https://lore.kernel.org/all/CAKNNEtw5_kZomhkugedKMPOG- >>> sxs5Q5OLumWJdiWXv+C9Yct0w@mail.gmail.com/ >>> Signed-off-by: Zi Yan >>> Cc: >>> --- >> >> Thanks for the fix! >> >> I also made a C reproducer and tested this patch - the corruption >> disappeared. > > Should we link that reproducer somehow from the patch description? Yes, the original reproducer provided by Bas is available here[1]. Regarding the C reproducer, Zi plans to add it to selftests in a follow-up patch (as we discussed off-list). [1] https://github.com/dfinity/thp-madv-remove-test Cheers, Lance