kernel/linux.git/block/blk-settings.c, branch v6.18.22

block: validate pi_offset integrity limit

2026-01-17T15:35:33+00:00

[ Upstream commit ccb8a3c08adf8121e2afb8e704f007ce99324d79 ] The PI tuple must be contained within the metadata value, so validate that pi_offset + pi_tuple_size <= metadata_size. This guards against block drivers that report invalid pi_offset values. Signed-off-by: Caleb Sander Mateos Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin

block: require LBA dma_alignment when using PI

2025-10-22T16:02:54+00:00

The block layer PI generation / verification code expects the bio_vecs to have at least LBA size (or more correctly integrity internal) granularity. With the direct I/O alignment relaxation in 2022, user space can now feed bios with less alignment than that, leading to scribbling outside the PI buffers. Apparently this wasn't noticed so far because none of the tests generate such buffers, but since 851c4c96db00 ("xfs: implement XFS_IOC_DIOINFO in terms of vfs_getattr"), xfstests generic/013 by default generates such I/O now that the relaxed alignment is advertised by the XFS_IOC_DIOINFO ioctl. Fix this by increasing the required alignment when using PI, although handling arbitrary alignment in the long run would be even nicer. Fixes: bf8d08532bc1 ("iomap: add support for dma aligned direct-io") Fixes: b1a000d3b8ec ("block: relax direct io memory alignment") Signed-off-by: Christoph Hellwig Reviewed-by: Martin K. Petersen Reviewed-by: Keith Busch Signed-off-by: Jens Axboe

block: relax atomic write boundary vs chunk size check

2025-09-16T18:29:10+00:00

blk_validate_atomic_write_limits() ensures that any boundary fits into and is aligned to any chunk size. However, it should also be possible to fit the chunk size into any boundary. That check is already made in blk_stack_atomic_writes_boundary_head(). Relax the check in blk_validate_atomic_write_limits() by reusing (and renaming) blk_stack_atomic_writes_boundary_head(). Signed-off-by: John Garry Reviewed-by: Martin K. Petersen Signed-off-by: Jens Axboe

block: fix stacking of atomic writes when atomics are not supported

2025-09-16T18:29:10+00:00

Atomic writes support may not always be possible when stacking devices which support atomic writes. Such as case is a different atomic write boundary between stacked devices (which is not supported). In the case that atomic writes cannot supported, the top device queue HW limits are set to 0. However, in blk_stack_atomic_writes_limits(), we detect that we are stacking the first bottom device by checking the top device atomic_write_hw_max value == 0. This get confused with the case of atomic writes not supported, above. Make the distinction between stacking the first bottom device and no atomics supported by initializing stacked device atomic_write_hw_max = UINT_MAX and checking that for stacking the first bottom device. Fixes: d7f36dc446e8 ("block: Support atomic writes limits for stacked devices") Signed-off-by: John Garry Reviewed-by: Martin K. Petersen Signed-off-by: Jens Axboe

block: update validation of atomic writes boundary for stacked devices

2025-09-16T18:29:10+00:00

In commit 63d092d1c1b1 ("block: use chunk_sectors when evaluating stacked atomic write limits"), it was missed to use a chunk sectors limit check in blk_stack_atomic_writes_boundary_head(), so update that function to do the proper check. Fixes: 63d092d1c1b1 ("block: use chunk_sectors when evaluating stacked atomic write limits") Signed-off-by: John Garry Reviewed-by: Martin K. Petersen Signed-off-by: Jens Axboe

block: use int to store blk_stack_limits() return value

2025-09-03T01:19:25+00:00

Change the 'ret' variable in blk_stack_limits() from unsigned int to int, as it needs to store negative value -1. Storing the negative error codes in unsigned type, or performing equality comparisons (e.g., ret == -1), doesn't cause an issue at runtime [1] but can be confusing. Additionally, assigning negative error codes to unsigned type may trigger a GCC warning when the -Wsign-conversion flag is enabled. No effect on runtime. Link: https://lore.kernel.org/all/x3wogjf6vgpkisdhg3abzrx7v7zktmdnfmqeih5kosszmagqfs@oh3qxrgzkikf/ #1 Signed-off-by: Qianfeng Rong Reviewed-by: John Garry Fixes: fe0b393f2c0a ("block: Correct handling of bottom device misaligment") Reviewed-by: Bart Van Assche Link: https://lore.kernel.org/r/20250902130930.68317-1-rongqianfeng@vivo.com Signed-off-by: Jens Axboe

block: remove newlines from the warnings in blk_validate_integrity_limits

2025-08-18T16:17:49+00:00

Otherwise they are very hard to read in the kernel log. Signed-off-by: Christoph Hellwig Reviewed-by: Anuj Gupta Reviewed-by: Martin K. Petersen Link: https://lore.kernel.org/r/20250818045456.1482889-3-hch@lst.de Signed-off-by: Jens Axboe

block: handle pi_tuple_size in queue_limits_stack_integrity

2025-08-18T16:17:49+00:00

queue_limits_stack_integrity needs to handle the new pi_tuple_size field, otherwise stacking PI-capable devices will always fail. Fixes: 76e45252a4ce ("block: introduce pi_tuple_size field in blk_integrity") Signed-off-by: Christoph Hellwig Reviewed-by: Anuj Gupta Reviewed-by: Martin K. Petersen Link: https://lore.kernel.org/r/20250818045456.1482889-2-hch@lst.de Signed-off-by: Jens Axboe

block: ensure discard_granularity is zero when discard is not supported

2025-07-31T21:01:35+00:00

Documentation/ABI/stable/sysfs-block states: What: /sys/block//queue/discard_granularity [...] A discard_granularity of 0 means that the device does not support discard functionality. but this got broken when sorting out the block limits updates. Fix this by setting the discard_granularity limit to zero when the combined max_discard_sectors is zero. Fixes: 3c407dc723bb ("block: default the discard granularity to sector size") Signed-off-by: Christoph Hellwig Reviewed-by: Martin K. Petersen Link: https://lore.kernel.org/r/20250731152228.873923-1-hch@lst.de Signed-off-by: Jens Axboe

block: Enforce power-of-2 physical block size

2025-07-29T12:25:08+00:00

The merging/splitting code and other queue limits checking depends on the physical block size being a power-of-2, so enforce it. Reviewed-by: Martin K. Petersen Signed-off-by: John Garry Reviewed-by: Damien Le Moal Reviewed-by: Hannes Reinecke Link: https://lore.kernel.org/r/20250729091448.1691334-3-john.g.garry@oracle.com [axboe: add missing braces] Signed-off-by: Jens Axboe