On 2022/4/13 21:46, David Sterba wrote:
On Wed, Apr 13, 2022 at 07:32:41AM +0800, Qu Wenruo wrote:
On 2022/4/13 04:41, David Sterba wrote:
On Tue, Apr 12, 2022 at 08:30:13PM +0800, Qu Wenruo wrote:
The commit 1784b7d502a9 ("btrfs: handle csum lookup errors properly on
reads") itself is completely fine, it's our existing code not properly
handling the error from bio submission hook properly.
This patch will make submit_one_bio() to return void so that the callers
will never be able to do cleanup when bio submission hook fails.
CC: stable@xxxxxxxxxxxxxxx # 5.18+
BTW stable tags are only for released kernels, if it's still in some rc
then Fixes: is appropriate.
The problem is I don't have a good idea on which commit to be fixed.
Commit 1784b7d502a9 ("btrfs: handle csum lookup errors properly on
reads") is completely fine by itself.
The problem is there for a long long time, but can only be triggered
with IO errors with that newer commit.
Should we really use that commit? It looks like a scapegoat to me...
I see, so it does not make sense to put Fixes: if it's not clearly
caused by the patch, the text description of the problem and references
to patches that could affect is OK.
Still the stable tag should reflect where the fix applies but 5.18
hasn't been released so either it's a typo or you know roughly which
stable kernels should get the fix (5.15, 5.10, etc).
Then I guess we can drop the stable tag.
Before that mentioned commit, btrfs_lookup_bio_csum() will never return
error, thus submit_one_bio() will not really fail (due to IO error).
Although the error path is there for a long long time, we don't have
easy way to trigger the problem.
Thanks,
Qu
