| Message ID | 20250312050028.1784117-1-mcgrof@kernel.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | block: add BLK_FEAT_LBS to check for PAGE_SIZE limit | expand |
On Tue, Mar 11, 2025 at 10:00:28PM -0700, Luis Chamberlain wrote: > We should take time to validate each block driver before enabling > support for larger logical block sizes, so that those that didn't > have support stay that way and don't need modifications. > > Li Wang reported this as a regression on LTP via: > > testcases/kernel/syscalls/ioctl/ioctl_loop06 > > Which uses the loopback driver to enable larger logical block sizes > first with LOOP_CONFIGURE and then LOOP_SET_BLOCK_SIZE. While > I see no reason why the loopback block driver can't support > larger logical block sizes than PAGE_SIZE, leave this validation > step as a secondary effort for each block driver. This doesn't really make sense. We don't want a flag that caps driver controlled values at a arbitrary value (and then not used it at all in the patch). If you need extra per-driver validatation, do it in the driver.
On Wed, Mar 12, 2025 at 06:21:55AM +0100, Christoph Hellwig wrote: > On Tue, Mar 11, 2025 at 10:00:28PM -0700, Luis Chamberlain wrote: > > We should take time to validate each block driver before enabling > > support for larger logical block sizes, so that those that didn't > > have support stay that way and don't need modifications. > > > > Li Wang reported this as a regression on LTP via: > > > > testcases/kernel/syscalls/ioctl/ioctl_loop06 > > > > Which uses the loopback driver to enable larger logical block sizes > > first with LOOP_CONFIGURE and then LOOP_SET_BLOCK_SIZE. While > > I see no reason why the loopback block driver can't support > > larger logical block sizes than PAGE_SIZE, leave this validation > > step as a secondary effort for each block driver. > > This doesn't really make sense. We don't want a flag that caps driver > controlled values at a arbitrary value (and then not used it at all in > the patch). > > If you need extra per-driver validatation, do it in the driver. Are you suggesting we just move back the PAGE_SIZE check, or to keep the checks for the block driver limits into each driver? Luis
On Tue, Mar 11, 2025 at 10:37:27PM -0700, Luis Chamberlain wrote: > > If you need extra per-driver validatation, do it in the driver. > > Are you suggesting we just move back the PAGE_SIZE check, PAGE_SIZE now is a consumer (i.e. file system) limitation. Having a flag in the provider (driver) does not make sense. > or to keep > the checks for the block driver limits into each driver? Most drivers probably don't have a limit other than than that implicit by the field width used for reporting. So in general the driver should not need any checks. The only exceptions might be for virtual drivers where the value comes from userspace, but even then it is a bit doubtful.
On Wed, Mar 12, 2025 at 06:40:53AM +0100, Christoph Hellwig wrote: > On Tue, Mar 11, 2025 at 10:37:27PM -0700, Luis Chamberlain wrote: > > > If you need extra per-driver validatation, do it in the driver. > > > > Are you suggesting we just move back the PAGE_SIZE check, > > PAGE_SIZE now is a consumer (i.e. file system) limitation. Having > a flag in the provider (driver) does not make sense. > > > or to keep > > the checks for the block driver limits into each driver? > > Most drivers probably don't have a limit other than than that implicit > by the field width used for reporting. So in general the driver should > not need any checks. The only exceptions might be for virtual drivers > where the value comes from userspace, but even then it is a bit doubtful. Alrighty, so silly tests just need to be updated. If a hang is reported, we can look into it, or just add block driver checks / limitations. Luis
diff --git a/block/blk-settings.c b/block/blk-settings.c index c44dadc35e1e..5cdd0d7d2af2 100644 --- a/block/blk-settings.c +++ b/block/blk-settings.c @@ -254,7 +254,9 @@ int blk_validate_limits(struct queue_limits *lim) */ if (!lim->logical_block_size) lim->logical_block_size = SECTOR_SIZE; - else if (blk_validate_block_size(lim->logical_block_size)) { + else if (blk_validate_block_size(lim->logical_block_size) || + (lim->logical_block_size > PAGE_SIZE && + !(lim->features & BLK_FEAT_LBS))) { pr_warn("Invalid logical block size (%d)\n", lim->logical_block_size); return -EINVAL; } diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index a97428e8bbbe..cdab3731a646 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -341,6 +341,9 @@ typedef unsigned int __bitwise blk_features_t; #define BLK_FEAT_ATOMIC_WRITES \ ((__force blk_features_t)(1u << 16)) +/* Supports sector sizes > PAGE_SIZE */ +#define BLK_FEAT_LBS ((__force blk_features_t)(1u << 17)) + /* * Flags automatically inherited when stacking limits. */
The commit titled "block/bdev: lift block size restrictions to 64k" lifted the block layer's max supported block size to 64k inside the helper blk_validate_block_size() now that we support large folios on the block layer. However, block drivers have relied on the call for queue_limits_commit_update() to validate and ensure the logical block size < PAGE_SIZE. We should take time to validate each block driver before enabling support for larger logical block sizes, so that those that didn't have support stay that way and don't need modifications. Li Wang reported this as a regression on LTP via: testcases/kernel/syscalls/ioctl/ioctl_loop06 Which uses the loopback driver to enable larger logical block sizes first with LOOP_CONFIGURE and then LOOP_SET_BLOCK_SIZE. While I see no reason why the loopback block driver can't support larger logical block sizes than PAGE_SIZE, leave this validation step as a secondary effort for each block driver. Reported-by: Li Wang <liwang@redhat.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-lkp/202503101538.84c33cd4-lkp@intel.com Signed-off-by: Luis Chamberlain <mcgrof@kernel.org> --- block/blk-settings.c | 4 +++- include/linux/blkdev.h | 3 +++ 2 files changed, 6 insertions(+), 1 deletion(-)