From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relayaws-01.paragon-software.com (relayaws-01.paragon-software.com [35.157.23.187]) (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 0A2FA3D25DD for ; Tue, 26 May 2026 10:03:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=35.157.23.187 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779789786; cv=none; b=MU9F0B0wy1BOGm1Lwp7XsIKSUrRBgf0WBapDXbmngHh1pLLe3hVVsEoX7f7nqJB5NAGJQjGBoc008Zsg2JRZhE99eoUwyz50GdMnabT6nyEGIpnWvVOvVuINe96ZzXq+kJWWMPBoTrAAsthOZKHgAuufNxS1edKWauEPGHvQjNk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779789786; c=relaxed/simple; bh=eFEeIYKjNbU5jL+tQfHzE8wfMHEP2ya4AyRvD1y+UNE=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=IVi4pSeGEO6EbsJUVkGJqv9dcSuMxFx8QYkD+CSapahDn2yOjnMILw6Od78OsoMfVpMHvNq8aKMP5kKacNJhv/MCT9XxYxYzqgiTR3QxOW1HQsM8uSmDU718KK/4cDrJ0rIKn084+B8RkFCNpT0JkPoF53PT5DdsaegkwCYNeyE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=paragon-software.com; spf=pass smtp.mailfrom=paragon-software.com; dkim=pass (1024-bit key) header.d=paragon-software.com header.i=@paragon-software.com header.b=V+hATw3P; arc=none smtp.client-ip=35.157.23.187 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=paragon-software.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=paragon-software.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=paragon-software.com header.i=@paragon-software.com header.b="V+hATw3P" Received: from relayfre-01.paragon-software.com (relayfre-01.paragon-software.com [176.12.100.13]) by relayaws-01.paragon-software.com (Postfix) with ESMTPS id 8646D1D19; Tue, 26 May 2026 10:03:04 +0000 (UTC) Authentication-Results: relayaws-01.paragon-software.com; dkim=pass (1024-bit key; unprotected) header.d=paragon-software.com header.i=@paragon-software.com header.b=V+hATw3P; dkim-atps=neutral Received: from dlg2.mail.paragon-software.com (vdlg-exch-02.paragon-software.com [172.30.1.105]) by relayfre-01.paragon-software.com (Postfix) with ESMTPS id B98CA2126; Tue, 26 May 2026 10:03:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paragon-software.com; s=mail; t=1779789781; bh=wiBCkHS0siR+fKkYw8QTVcc0ibKKuNZmQi95NZ0/UpU=; h=Date:Subject:To:CC:References:From:In-Reply-To; b=V+hATw3PwWIJ+5tOT+sAXM3LSCm8k5rMiky3qUOra8wGjqBvjJKMgNMcqq1jOa3Wj n18lnb10UQaqdhktOjguDMDSNyiIr4fPv0qyFSJx0WgS70fVQDzr5e2n0A5skhsLIa /3rwp7nYjbewb2gFQHd8NS+rL6TMTohDQ1miBXl4= Received: from [192.168.95.128] (172.30.20.153) by vdlg-exch-02.paragon-software.com (172.30.1.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.7; Tue, 26 May 2026 13:03:00 +0300 Message-ID: <796d10d5-7aef-470d-a2fb-3d5d70a95805@paragon-software.com> Date: Tue, 26 May 2026 12:02:59 +0200 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] fs/ntfs3: fix wrong LCN in run_remove_range() when splitting a run To: Zhan Xusheng CC: , Zhan Xusheng References: <20260508095245.78254-1-zhanxusheng@xiaomi.com> Content-Language: en-US From: Konstantin Komarov In-Reply-To: <20260508095245.78254-1-zhanxusheng@xiaomi.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: vdlg-exch-02.paragon-software.com (172.30.1.105) To vdlg-exch-02.paragon-software.com (172.30.1.105) On 5/8/26 11:52, Zhan Xusheng wrote: > When run_remove_range() removes a middle portion of a non-sparse run, > it splits the run into head and tail parts. The tail is inserted via > run_add_entry() but uses the original r->lcn as its starting LCN > instead of advancing it by the split offset. > > For example, removing VCN range [10, 20) from a run > {vcn=0, lcn=100, len=30} should produce: > {vcn=0, lcn=100, len=10} (head) > {vcn=20, lcn=120, len=10} (tail, lcn advanced by 20) > > But the current code produces: > {vcn=0, lcn=100, len=10} > {vcn=20, lcn=100, len=10} (wrong: points to same physical clusters) > > This creates overlapping physical mappings in the in-memory run tree, > which can corrupt cluster allocation decisions and lead to data > corruption. > > The correct pattern is already used in run_insert_range(): > CLST lcn2 = r->lcn == SPARSE_LCN ? SPARSE_LCN : (r->lcn + len1); > > Apply the same logic in run_remove_range(). > > Fixes: 10d7c95af043 ("fs/ntfs3: add delayed-allocation (delalloc) support") > Signed-off-by: Zhan Xusheng > --- > fs/ntfs3/run.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/fs/ntfs3/run.c b/fs/ntfs3/run.c > index 1ce7d92fb274..cca6bdf2e7aa 100644 > --- a/fs/ntfs3/run.c > +++ b/fs/ntfs3/run.c > @@ -1292,9 +1292,12 @@ bool run_remove_range(struct runs_tree *run, CLST vcn, CLST len, CLST *done) > > if (r_end > end) { > /* Remove a middle part, split. */ > + CLST tail_lcn = r->lcn == SPARSE_LCN ? > + SPARSE_LCN : (r->lcn + (end - r->vcn)); > + > *done += len; > r->len = d; > - return run_add_entry(run, end, r->lcn, r_end - end, > + return run_add_entry(run, end, tail_lcn, r_end - end, > false); > } > /* Remove tail of run .*/ Hello, Queued for the next merge window, thank you. Regards, Konstantin