FAILED: patch "[PATCH] dm verity: fix error handling for check_at_most_once on FEC" failed to apply to 5.10-stable tree
The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x e8c5d45f82ce0c238a4817739892fe8897a3dcc3 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to 'stable@vger.kernel.org' --in-reply-to '2023050701-epileptic-unethical-f46c@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^..
Possible dependencies:
e8c5d45f82ce ("dm verity: fix error handling for check_at_most_once on FEC")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From e8c5d45f82ce0c238a4817739892fe8897a3dcc3 Mon Sep 17 00:00:00 2001 From: Yeongjin Gil youngjin.gil@samsung.com Date: Mon, 20 Mar 2023 15:59:32 +0900 Subject: [PATCH] dm verity: fix error handling for check_at_most_once on FEC
In verity_end_io(), if bi_status is not BLK_STS_OK, it can be return directly. But if FEC configured, it is desired to correct the data page through verity_verify_io. And the return value will be converted to blk_status and passed to verity_finish_io().
BTW, when a bit is set in v->validated_blocks, verity_verify_io() skips verification regardless of I/O error for the corresponding bio. In this case, the I/O error could not be returned properly, and as a result, there is a problem that abnormal data could be read for the corresponding block.
To fix this problem, when an I/O error occurs, do not skip verification even if the bit related is set in v->validated_blocks.
Fixes: 843f38d382b1 ("dm verity: add 'check_at_most_once' option to only validate hashes once") Cc: stable@vger.kernel.org Reviewed-by: Sungjong Seo sj1557.seo@samsung.com Signed-off-by: Yeongjin Gil youngjin.gil@samsung.com Signed-off-by: Mike Snitzer snitzer@kernel.org
diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c index ade83ef3b439..9316399b920e 100644 --- a/drivers/md/dm-verity-target.c +++ b/drivers/md/dm-verity-target.c @@ -523,7 +523,7 @@ static int verity_verify_io(struct dm_verity_io *io) sector_t cur_block = io->block + b; struct ahash_request *req = verity_io_hash_req(v, io);
- if (v->validated_blocks && + if (v->validated_blocks && bio->bi_status == BLK_STS_OK && likely(test_bit(cur_block, v->validated_blocks))) { verity_bv_skip_block(v, io, iter); continue;
In verity_end_io(), if bi_status is not BLK_STS_OK, it can be return directly. But if FEC configured, it is desired to correct the data page through verity_verify_io. And the return value will be converted to blk_status and passed to verity_finish_io().
BTW, when a bit is set in v->validated_blocks, verity_verify_io() skips verification regardless of I/O error for the corresponding bio. In this case, the I/O error could not be returned properly, and as a result, there is a problem that abnormal data could be read for the corresponding block.
To fix this problem, when an I/O error occurs, do not skip verification even if the bit related is set in v->validated_blocks.
Fixes: 843f38d382b1 ("dm verity: add 'check_at_most_once' option to only validate hashes once") Cc: stable@vger.kernel.org Reviewed-by: Sungjong Seo sj1557.seo@samsung.com Signed-off-by: Yeongjin Gil youngjin.gil@samsung.com Signed-off-by: Mike Snitzer snitzer@kernel.org (cherry picked from commit e8c5d45f82ce0c238a4817739892fe8897a3dcc3) --- drivers/md/dm-verity-target.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c index c801f6b93b7b..72168ea5fe52 100644 --- a/drivers/md/dm-verity-target.c +++ b/drivers/md/dm-verity-target.c @@ -481,7 +481,7 @@ static int verity_verify_io(struct dm_verity_io *io) sector_t cur_block = io->block + b; struct ahash_request *req = verity_io_hash_req(v, io);
- if (v->validated_blocks && + if (v->validated_blocks && bio->bi_status == BLK_STS_OK && likely(test_bit(cur_block, v->validated_blocks))) { verity_bv_skip_block(v, io, &io->iter); continue;
In verity_end_io(), if bi_status is not BLK_STS_OK, it can be return directly. But if FEC configured, it is desired to correct the data page through verity_verify_io. And the return value will be converted to blk_status and passed to verity_finish_io().
BTW, when a bit is set in v->validated_blocks, verity_verify_io() skips verification regardless of I/O error for the corresponding bio. In this case, the I/O error could not be returned properly, and as a result, there is a problem that abnormal data could be read for the corresponding block.
To fix this problem, when an I/O error occurs, do not skip verification even if the bit related is set in v->validated_blocks.
Fixes: 843f38d382b1 ("dm verity: add 'check_at_most_once' option to only validate hashes once") Cc: stable@vger.kernel.org Reviewed-by: Sungjong Seo sj1557.seo@samsung.com Signed-off-by: Yeongjin Gil youngjin.gil@samsung.com Signed-off-by: Mike Snitzer snitzer@kernel.org (cherry picked from commit e8c5d45f82ce0c238a4817739892fe8897a3dcc3) --- drivers/md/dm-verity-target.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c index c801f6b93b7b..450377655791 100644 --- a/drivers/md/dm-verity-target.c +++ b/drivers/md/dm-verity-target.c @@ -475,13 +475,14 @@ static int verity_verify_io(struct dm_verity_io *io) struct bvec_iter start; unsigned b; struct crypto_wait wait; + struct bio *bio = dm_bio_from_per_bio_data(io, v->ti->per_io_data_size);
for (b = 0; b < io->n_blocks; b++) { int r; sector_t cur_block = io->block + b; struct ahash_request *req = verity_io_hash_req(v, io);
- if (v->validated_blocks && + if (v->validated_blocks && bio->bi_status == BLK_STS_OK && likely(test_bit(cur_block, v->validated_blocks))) { verity_bv_skip_block(v, io, &io->iter); continue;
In verity_end_io(), if bi_status is not BLK_STS_OK, it can be return directly. But if FEC configured, it is desired to correct the data page through verity_verify_io. And the return value will be converted to blk_status and passed to verity_finish_io().
BTW, when a bit is set in v->validated_blocks, verity_verify_io() skips verification regardless of I/O error for the corresponding bio. In this case, the I/O error could not be returned properly, and as a result, there is a problem that abnormal data could be read for the corresponding block.
To fix this problem, when an I/O error occurs, do not skip verification even if the bit related is set in v->validated_blocks.
Fixes: 843f38d382b1 ("dm verity: add 'check_at_most_once' option to only validate hashes once") Cc: stable@vger.kernel.org Reviewed-by: Sungjong Seo sj1557.seo@samsung.com Signed-off-by: Yeongjin Gil youngjin.gil@samsung.com Signed-off-by: Mike Snitzer snitzer@kernel.org (cherry picked from commit e8c5d45f82ce0c238a4817739892fe8897a3dcc3) --- v2: -Add bio definition in verity_verify_io --- drivers/md/dm-verity-target.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c index c801f6b93b7b..450377655791 100644 --- a/drivers/md/dm-verity-target.c +++ b/drivers/md/dm-verity-target.c @@ -475,13 +475,14 @@ static int verity_verify_io(struct dm_verity_io *io) struct bvec_iter start; unsigned b; struct crypto_wait wait; + struct bio *bio = dm_bio_from_per_bio_data(io, v->ti->per_io_data_size);
for (b = 0; b < io->n_blocks; b++) { int r; sector_t cur_block = io->block + b; struct ahash_request *req = verity_io_hash_req(v, io);
- if (v->validated_blocks && + if (v->validated_blocks && bio->bi_status == BLK_STS_OK && likely(test_bit(cur_block, v->validated_blocks))) { verity_bv_skip_block(v, io, &io->iter); continue;
On Mon, May 15, 2023 at 10:18:16AM +0900, Yeongjin Gil wrote:
In verity_end_io(), if bi_status is not BLK_STS_OK, it can be return directly. But if FEC configured, it is desired to correct the data page through verity_verify_io. And the return value will be converted to blk_status and passed to verity_finish_io().
BTW, when a bit is set in v->validated_blocks, verity_verify_io() skips verification regardless of I/O error for the corresponding bio. In this case, the I/O error could not be returned properly, and as a result, there is a problem that abnormal data could be read for the corresponding block.
To fix this problem, when an I/O error occurs, do not skip verification even if the bit related is set in v->validated_blocks.
Fixes: 843f38d382b1 ("dm verity: add 'check_at_most_once' option to only validate hashes once") Cc: stable@vger.kernel.org Reviewed-by: Sungjong Seo sj1557.seo@samsung.com Signed-off-by: Yeongjin Gil youngjin.gil@samsung.com Signed-off-by: Mike Snitzer snitzer@kernel.org (cherry picked from commit e8c5d45f82ce0c238a4817739892fe8897a3dcc3)
Why did you send this 3 times?
And what kernel(s) is this to be applied to?
confused,
greg k-h
On Mon, May 15, 2023 at 10:18:16AM +0900, Yeongjin Gil wrote:
In verity_end_io(), if bi_status is not BLK_STS_OK, it can be return directly. But if FEC configured, it is desired to correct the data page through verity_verify_io. And the return value will be converted to blk_status and passed to verity_finish_io().
BTW, when a bit is set in v->validated_blocks, verity_verify_io() skips verification regardless of I/O error for the corresponding bio. In this case, the I/O error could not be returned properly, and as a result, there is a problem that abnormal data could be read for the corresponding block.
To fix this problem, when an I/O error occurs, do not skip verification even if the bit related is set in v->validated_blocks.
Fixes: 843f38d382b1 ("dm verity: add 'check_at_most_once' option to only validate hashes once") Cc: stable@vger.kernel.org Reviewed-by: Sungjong Seo sj1557.seo@samsung.com Signed-off-by: Yeongjin Gil youngjin.gil@samsung.com Signed-off-by: Mike Snitzer snitzer@kernel.org (cherry picked from commit e8c5d45f82ce0c238a4817739892fe8897a3dcc3)
Why did you send this 3 times?
And what kernel(s) is this to be applied to?
confused,
I'm sorry for the confusion.
I've got patch failure mail 3 times from 4.19-stable, 5.4-stable, 5.10-stable. So I replied to each mail after conflict resolution. --in-reply-to '2023050708-verdict-proton-a5f0@gregkh' --in-reply-to '2023050709-dry-stand-f81b@gregkh' --in-reply-to '2023050701-epileptic-unethical-f46c@gregkh'
The stable kernel branches that I want to be applied are the above kernels.
greg k-h
On Mon, May 15, 2023 at 01:06:07PM +0900, Yeongjin Gil wrote:
On Mon, May 15, 2023 at 10:18:16AM +0900, Yeongjin Gil wrote:
In verity_end_io(), if bi_status is not BLK_STS_OK, it can be return directly. But if FEC configured, it is desired to correct the data page through verity_verify_io. And the return value will be converted to blk_status and passed to verity_finish_io().
BTW, when a bit is set in v->validated_blocks, verity_verify_io() skips verification regardless of I/O error for the corresponding bio. In this case, the I/O error could not be returned properly, and as a result, there is a problem that abnormal data could be read for the corresponding block.
To fix this problem, when an I/O error occurs, do not skip verification even if the bit related is set in v->validated_blocks.
Fixes: 843f38d382b1 ("dm verity: add 'check_at_most_once' option to only validate hashes once") Cc: stable@vger.kernel.org Reviewed-by: Sungjong Seo sj1557.seo@samsung.com Signed-off-by: Yeongjin Gil youngjin.gil@samsung.com Signed-off-by: Mike Snitzer snitzer@kernel.org (cherry picked from commit e8c5d45f82ce0c238a4817739892fe8897a3dcc3)
Why did you send this 3 times?
And what kernel(s) is this to be applied to?
confused,
I'm sorry for the confusion.
I've got patch failure mail 3 times from 4.19-stable, 5.4-stable, 5.10-stable. So I replied to each mail after conflict resolution. --in-reply-to '2023050708-verdict-proton-a5f0@gregkh' --in-reply-to '2023050709-dry-stand-f81b@gregkh' --in-reply-to '2023050701-epileptic-unethical-f46c@gregkh'
The stable kernel branches that I want to be applied are the above kernels.
Ah, I lost the sending email from my inbox, as I don't keep that around, so that's why I missed this, thanks.
Looks like this is already all queued up by Sasha, so thanks!
greg k-h
linux-stable-mirror@lists.linaro.org
-
'Greg KH' -
Greg KH
-
gregkh＠linuxfoundation.org
-
Yeongjin Gil