linux-stable.git/block, branch v6.14.3

block: make sure ->nr_integrity_segments is cloned in blk_rq_prep_clone

2025-04-20T08:22:55+00:00

commit fc0e982b8a3a169b1c654d9a1aa45bf292943ef2 upstream.

Make sure ->nr_integrity_segments is cloned in blk_rq_prep_clone(),
otherwise requests cloned by device-mapper multipath will not have the
proper nr_integrity_segments values set, then BUG() is hit from
sg_alloc_table_chained().

Fixes: b0fd271d5fba ("block: add request clone interface (v2)")
Cc: stable@vger.kernel.org
Cc: Christoph Hellwig 
Signed-off-by: Ming Lei 
Reviewed-by: Christoph Hellwig 
Link: https://lore.kernel.org/r/20250310115453.2271109-1-ming.lei@redhat.com
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

block: fix adding folio to bio

2025-04-10T12:44:08+00:00

[ Upstream commit 26064d3e2b4d9a14df1072980e558c636fb023ea ]

>4GB folio is possible on some ARCHs, such as aarch64, 16GB hugepage
is supported, then 'offset' of folio can't be held in 'unsigned int',
cause warning in bio_add_folio_nofail() and IO failure.

Fix it by adjusting 'page' & trimming 'offset' so that `->bi_offset` won't
be overflow, and folio can be added to bio successfully.

Fixes: ed9832bc08db ("block: introduce folio awareness and add a bigger size from folio")
Cc: Kundan Kumar 
Cc: Matthew Wilcox (Oracle) 
Cc: Christoph Hellwig 
Cc: Luis Chamberlain 
Cc: Gavin Shan 
Signed-off-by: Ming Lei 
Reviewed-by: Matthew Wilcox (Oracle) 
Link: https://lore.kernel.org/r/20250312145136.2891229-1-ming.lei@redhat.com
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

badblocks: use sector_t instead of int to avoid truncation of badblocks length

2025-04-10T12:44:06+00:00

[ Upstream commit d301f164c3fbff611bd71f57dfa553b9219f0f5e ]

There is a truncation of badblocks length issue when set badblocks as
follow:

echo "2055 4294967299" > bad_blocks
cat bad_blocks
2055 3

Change 'sectors' argument type from 'int' to 'sector_t'.

This change avoids truncation of badblocks length for large sectors by
replacing 'int' with 'sector_t' (u64), enabling proper handling of larger
disk sizes and ensuring compatibility with 64-bit sector addressing.

Fixes: 9e0e252a048b ("badblocks: Add core badblock management code")
Signed-off-by: Zheng Qixing 
Reviewed-by: Yu Kuai 
Acked-by: Coly Li 
Link: https://lore.kernel.org/r/20250227075507.151331-13-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

badblocks: return boolean from badblocks_set() and badblocks_clear()

2025-04-10T12:44:06+00:00

[ Upstream commit c8775aefba959cdfbaa25408a84d3dd15bbeb991 ]

Change the return type of badblocks_set() and badblocks_clear()
from int to bool, indicating success or failure. Specifically:

- _badblocks_set() and _badblocks_clear() functions now return
true for success and false for failure.
- All calls to these functions are updated to handle the new
boolean return type.
- This change improves code clarity and ensures a more consistent
handling of success and failure states.

Signed-off-by: Zheng Qixing 
Reviewed-by: Yu Kuai 
Acked-by: Coly Li 
Acked-by: Ira Weiny 
Link: https://lore.kernel.org/r/20250227075507.151331-11-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe 
Stable-dep-of: d301f164c3fb ("badblocks: use sector_t instead of int to avoid truncation of badblocks length")
Signed-off-by: Sasha Levin

badblocks: fix missing bad blocks on retry in _badblocks_check()

2025-04-10T12:44:06+00:00

[ Upstream commit 5236f041fa6c81c71eabad44897e54a0d6d5bbf6 ]

The bad blocks check would miss bad blocks when retrying under contention,
as checking parameters are not reset. These stale values from the previous
attempt could lead to incorrect scanning in the subsequent retry.

Move seqlock to outer function and reinitialize checking state for each
retry. This ensures a clean state for each check attempt, preventing any
missed bad blocks.

Fixes: 3ea3354cb9f0 ("badblocks: improve badblocks_check() for multiple ranges handling")
Signed-off-by: Zheng Qixing 
Reviewed-by: Yu Kuai 
Acked-by: Coly Li 
Link: https://lore.kernel.org/r/20250227075507.151331-10-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

badblocks: fix merge issue when new badblocks align with pre+1

2025-04-10T12:44:06+00:00

[ Upstream commit 9ec65dec634a752ab0a1203510ee190356e4cf1a ]

There is a merge issue when adding badblocks as follow:
  echo 0 10 > bad_blocks
  echo 30 10 > bad_blocks
  echo 20 10 > bad_blocks
  cat bad_blocks
  0 10
  20 10    //should be merged with (30 10)
  30 10

In this case, if new badblocks does not intersect with prev, it is added
by insert_at(). If there is an intersection with prev+1, the merge will
be processed in the next re_insert loop.

However, when the end of the new badblocks is exactly equal to the offset
of prev+1, no further re_insert loop occurs, and the two badblocks are not
merge.

Fix it by inc prev, badblocks can be merged during the subsequent code.

Fixes: aa511ff8218b ("badblocks: switch to the improved badblock handling code")
Signed-off-by: Li Nan 
Reviewed-by: Yu Kuai 
Link: https://lore.kernel.org/r/20250227075507.151331-9-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

badblocks: fix the using of MAX_BADBLOCKS

2025-04-10T12:44:06+00:00

[ Upstream commit 37446680dfbfbba7cbedd680047182f70a0b857b ]

The number of badblocks cannot exceed MAX_BADBLOCKS, but it should be
allowed to equal MAX_BADBLOCKS.

Fixes: aa511ff8218b ("badblocks: switch to the improved badblock handling code")
Fixes: c3c6a86e9efc ("badblocks: add helper routines for badblock ranges handling")
Signed-off-by: Li Nan 
Reviewed-by: Zhu Yanjun 
Reviewed-by: Yu Kuai 
Acked-by: Coly Li 
Link: https://lore.kernel.org/r/20250227075507.151331-7-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

badblocks: return error if any badblock set fails

2025-04-10T12:44:06+00:00

[ Upstream commit 7f500f0a59b1d7345a05ec4ae703babf34b7e470 ]

_badblocks_set() returns success if at least one badblock is set
successfully, even if others fail. This can lead to data inconsistencies
in raid, where a failed badblock set should trigger the disk to be kicked
out to prevent future reads from failed write areas.

_badblocks_set() should return error if any badblock set fails. Instead
of relying on 'rv', directly returning 'sectors' for clearer logic. If all
badblocks are successfully set, 'sectors' will be 0, otherwise it
indicates the number of badblocks that have not been set yet, thus
signaling failure.

By the way, it can also fix an issue: when a newly set unack badblock is
included in an existing ack badblock, the setting will return an error.
···
  echo "0 100" /sys/block/md0/md/dev-loop1/bad_blocks
  echo "0 100" /sys/block/md0/md/dev-loop1/unacknowledged_bad_blocks
  -bash: echo: write error: No space left on device
```
After fix, it will return success.

Fixes: aa511ff8218b ("badblocks: switch to the improved badblock handling code")
Signed-off-by: Li Nan 
Reviewed-by: Yu Kuai 
Acked-by: Coly Li 
Link: https://lore.kernel.org/r/20250227075507.151331-6-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

badblocks: return error directly when setting badblocks exceeds 512

2025-04-10T12:44:06+00:00

[ Upstream commit 28243dcd1f49cc8be398a1396d16a45527882ce5 ]

In the current handling of badblocks settings, a lot of processing has
been done for scenarios where the number of badblocks exceeds 512.
This makes the code look quite complex and also introduces some issues,

For example, if there is 512 badblocks already:
  for((i=0; i<510; i++)); do ((sector=i*2)); echo "$sector 1" > bad_blocks; done
  echo 2100 10 > bad_blocks
  echo 2200 10 > bad_blocks
Set new one, exceed 512:
  echo 2000 500 > bad_blocks
Expected:
  2000 500
Actual:
  2100 400

In fact, a disk shouldn't have too many badblocks, and for disks with
512 badblocks, attempting to set more bad blocks doesn't make much sense.
At that point, the more appropriate action would be to replace the disk.
Therefore, to resolve these issues and simplify the code somewhat, return
error directly when setting badblocks exceeds 512.

Fixes: aa511ff8218b ("badblocks: switch to the improved badblock handling code")
Signed-off-by: Li Nan 
Reviewed-by: Yu Kuai 
Link: https://lore.kernel.org/r/20250227075507.151331-5-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

badblocks: attempt to merge adjacent badblocks during ack_all_badblocks

2025-04-10T12:44:06+00:00

[ Upstream commit 32e9ad4d11f69949ff331e35a417871ee0d31d99 ]

If ack and unack badblocks are adjacent, they will not be merged and will
remain as two separate badblocks. Even after the bad blocks are written
to disk and both become ack, they will still remain as two independent
bad blocks. This is not ideal as it wastes the limited space for
badblocks. Therefore, during ack_all_badblocks(), attempt to merge
badblocks if they are adjacent.

Fixes: aa511ff8218b ("badblocks: switch to the improved badblock handling code")
Signed-off-by: Li Nan 
Reviewed-by: Yu Kuai 
Acked-by: Coly Li 
Link: https://lore.kernel.org/r/20250227075507.151331-4-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin