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 0281033A71B for ; Mon, 3 Aug 2026 08:38:09 +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=1785746291; cv=none; b=kE7m32QYhHsPzwRXyU9WCrkFeWl31ioJYSSbAfpttJhTlJmSl1iEwfcEpjq7FkcJqc0bLAdbxefgz57TiwyrH7OnKZHrjFpbHX5I6qeFooQuZk/BWRtLREUIR9gj2bf3tOrhDOAzuzz5f6YK3Nn0L7jETfK89bdGEZYv4xn8/gU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785746291; c=relaxed/simple; bh=bVWIaIFSOah1ef2BSK7h3qWrbzP0cVyMK+0rvUmRL0E=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=lg/scjWtaRt/XH2dYzfApRDfd0m18NZxIhkWEVG5MKtElgLZULd30pojObP0WDmDldFORJgAHGssQvy91b0EKoV/3HNSVaFsWjPuGgB04L8YUelsjEj33HyFHTVrwsYQ+kNvz+kNxTtPxh0Mbpvh8isRK7Qmgh1/Xi1hfRpM01s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZyCpFj1b; 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="ZyCpFj1b" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 17B851F000E9; Mon, 3 Aug 2026 08:38:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785746289; bh=WQ5o/ZS88bX3vd4nCEy6hjeaPlzSqlhG9oApBltnFQs=; h=Date:Cc:Subject:To:References:From:In-Reply-To; b=ZyCpFj1bAj6C/EoMGPixNTbuEHEr7WvD2uM0TgWTN57rT6m3R2T+UqY6PBZ+tVVH9 mibmvtL0/StwOvHAI+LujlpGpFLxeY+jXrt9e5veGyawPLkB2MuylU2blHalWY9M6o jEgWsYdgDeiRPWmZiZ+yMnHDqrRM86oCdHhyJjFYT9qrZYZ/6GJI2/1ZSAXOFNMyRm 6XotQF+8jndXGmjpP0VG+GuNP7PAR42CPw6G+YE/pshr4WGO8tFaixK9ws5oYYItxZ yMKdnNvjmZpLonTN7HHOn0gf6lVpECGYooNkVIx1dx7ulQmthjbx3Nbim1Pen9r0yT pUkLUc2OljDDg== Message-ID: <4e5ffe9b-6f93-4210-95cb-918686c17639@kernel.org> Date: Mon, 3 Aug 2026 16:38:06 +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, stable@kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, qiwenjie@xiaomi.com Subject: Re: [PATCH] f2fs: only redirty pinned folios in redirty_blocks To: Wenjie Qi , jaegeuk@kernel.org References: <20260727130430.2109181-1-qiwenjie@xiaomi.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20260727130430.2109181-1-qiwenjie@xiaomi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7/27/26 21:04, Wenjie Qi wrote: > redirty_blocks() pins folios with read_cache_folio() and then walks the > same range again with filemap_lock_folio() to redirty them and drop the > references it took. > > Commit 5951fee46bef ("f2fs: Use a folio in redirty_blocks()") changed > the second pass to a do/while loop. If read_cache_folio() fails before > anything is pinned, page_idx does not advance but the cleanup loop still > runs once. > > If readahead has already populated the failed folio in page cache, that > extra iteration finds it and folio_put_refs(folio, 2) drops one > reference too many. Later drop_caches or reclaim can then report > "BUG: Bad page state". > > Only redirty the range that was pinned successfully. > > Fixes: 5951fee46bef ("f2fs: Use a folio in redirty_blocks()") > Cc: stable@kernel.org > Assisted-by: Codex:gpt-5.5 > Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Thanks,