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 75BCA2857C1 for ; Tue, 6 Jan 2026 09:16:37 +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=1767690997; cv=none; b=ez4+gGdLOwntHHWJ2sJtudLQsORSu1wQOjRu6R2w01gQayAib30OtVx5criuZwybTX5/w+UFoNabCgmVkpc2MbsOLginilR7IZzo3w8CQl964HFABFyUjmL8jhJGmHO28kkK2BZ4DXpdvmw9a9WZJgDav+EF/G84VcZWxec9Df4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767690997; c=relaxed/simple; bh=w+rWz+PbDxgIMU9MG/SZtQJ/F23YPFum6gNUrk/Kn8w=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=CWNTMUxyaA3iW24bCx1/blJbXog1/3DZ+npA+Ix3wQkyVoM0K0lJJCiFu7/t5nUmTaTS1HHbdTE40TifgozdfGJPdiahlMoaHbOkoI6cWHxkITP3Eb5WDICJ+DTscpRO7v5oiV5jSj80rhvz0YJuKmyaAbqh2O2tscYwcZxrtag= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RYQpuaxA; 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="RYQpuaxA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 10540C116C6; Tue, 6 Jan 2026 09:16:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767690997; bh=w+rWz+PbDxgIMU9MG/SZtQJ/F23YPFum6gNUrk/Kn8w=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=RYQpuaxAh++6fh9z2PVbSFNxV7jEz65wfL0bTad0fMA6QzM+inAmRnYyzXSj0N2lg MB/hSIRd9cczJac9k6qohQ477W71Cb9/qkubllnB9c6IEwWciZe5afYiMBkWTJcV0F TYCQEr6SmyEIcSoeTKbXM7T9+rxRKoF8mOLgaxL2j7RlzctAneSaFRzDSOLgT76i3+ LXivIPmdeXtzUv8BaC9wrfKiXqUyy3F1xRHTKYgVsvSTaPA2Y+hZBf0RwEsZl3PR+Y VFUrA72lBRc36vBGupdNbrK79wOALx0NyLK493Jzcqr94GwoWhVBYbnIjpb5wa5sDF syPYfo3GBxofA== Message-ID: <553c84d8-e0b3-4d02-a417-9e810142e8d6@kernel.org> Date: Tue, 6 Jan 2026 17:16:42 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: chao@kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 2/5] f2fs: Accounting large folio subpages before bio submission To: Nanzhe Zhao , Kim Jaegeuk References: <20260105153101.152892-1-nzzhao@126.com> <20260105153101.152892-3-nzzhao@126.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20260105153101.152892-3-nzzhao@126.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/5/2026 11:30 PM, Nanzhe Zhao wrote: > In f2fs_read_data_large_folio(), read_pages_pending is incremented only > after the subpage has been added to the BIO. With a heavily fragmented > file, each new subpage can force submission of the previous BIO. > > If the BIO completes quickly, f2fs_finish_read_bio() may decrement > read_pages_pending to zero and call folio_end_read() while the read loop > is still processing other subpages of the same large folio. > > Fix the ordering by incrementing read_pages_pending before any possible > BIO submission for the current subpage, matching the iomap ordering and > preventing premature folio_end_read(). > > Signed-off-by: Nanzhe Zhao Reviewed-by: Chao Yu Thanks,