NACK/Cmnt: [SRU][R][PATCH] Revert "block: Increase BLK_DEF_MAX_SECTORS_CAP"

Alex Shi alex.shi at canonical.com
Tue Sep 1 03:58:27 UTC 2026


For the bug: 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2148534, according 
to Yuri' testing, both of the patches work for this bug.

But the upstream has no response for both of patches (one of them are 
very similar with ours).
https://lore.kernel.org/linux-scsi/20260827175743.734593-1-t.lamprecht@proxmox.com/
https://lore.kernel.org/linux-scsi/GPhsSM0vkgyIrs0DIZ62qeUZX7X4RxwQXVKiuvMx-lHQVSPDxpztUyQOGS0xikqvJ-Z94hMV-dW_5KN_0CX2hsfV7kTf_t0MTf6vdAAaSEc=@magik.net/

*So do we need to wait for final decision from upstream or we could do 
it first, pick up one of them to use in our kernel?*

Thanks
Alex

On 2026/8/31 09:38, Alex Shi wrote:
> I have draft a new fix patch, and upstream has another patch for this 
> bug: 
> https://lore.kernel.org/linux-scsi/20260827182106.535D61F000E9@smtp.kernel.org/. 
>
> I have built them into 2 kernel image to let bug reporter test. And 
> now we are waiting for test result.
> In fact, both of solution are good. Let's wait for the upstream result?
>
> Thanks
> Alex
>
> On 2026/8/28 23:10, Alex Shi wrote:
>> Hi All
>>
>> Thanks for the comments and suggestion!
>> I have review this changes again.  And the current commit isn't good 
>> fix. The original commit has reasons.
>> So I gonna cook another better commit for this.
>>
>> Hi Jeff,
>> If lenove want this fix quickly, the current revert is a workable 
>> solution. I will check with Lenove's idea in the bug following.
>> Is this ok?
>>
>> Thanks
>> Alex
>>
>>
>> On 2026/8/27 02:10, Rickey Castillo Valenzuela wrote:
>>>
>>> On 8/26/26 05:26, Alex Shi via kernel-team wrote:
>>>> This reverts commit 9b8b84879d4adc506b0d3944e20b28d9f3f6994b to fix 
>>>> a OS
>>>> install failure on JBOD disk on B540d-2HS M.2 controller.
>>>>
>>>> Buglink: https://bugs.launchpad.net/bugs/2148534
>>>> Signed-off-by: Alex Shi <alex.shi at canonical.com>
>>>> ---
>>>>   block/blk.h            | 9 ---------
>>>>   include/linux/blkdev.h | 9 +++++++++
>>>>   2 files changed, 9 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/block/blk.h b/block/blk.h
>>>> index a7abf3be34ef..76da40c10fad 100644
>>>> --- a/block/blk.h
>>>> +++ b/block/blk.h
>>>> @@ -13,15 +13,6 @@
>>>>     struct elv_change_ctx;
>>>>   -/*
>>>> - * Default upper limit for the software max_sectors limit used for 
>>>> regular I/Os.
>>>> - * This can be increased through sysfs.
>>>> - *
>>>> - * This should not be confused with the max_hw_sector limit that 
>>>> is entirely
>>>> - * controlled by the block device driver, usually based on 
>>>> hardware limits.
>>>> - */
>>>> -#define BLK_DEF_MAX_SECTORS_CAP    (SZ_4M >> SECTOR_SHIFT)
>>>> -
>>>>   #define    BLK_DEV_MAX_SECTORS    (LLONG_MAX >> 9)
>>>>   #define    BLK_MIN_SEGMENT_SIZE    4096
>>>>   diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
>>>> index ac899cd0cd70..4469f1fe409c 100644
>>>> --- a/include/linux/blkdev.h
>>>> +++ b/include/linux/blkdev.h
>>>> @@ -1315,6 +1315,15 @@ enum blk_default_limits {
>>>>       BLK_SEG_BOUNDARY_MASK    = 0xFFFFFFFFUL,
>>>>   };
>>>>   +/*
>>>> + * Default upper limit for the software max_sectors limit used for
>>>> + * regular file system I/O.  This can be increased through sysfs.
>>>> + *
>>>> + * Not to be confused with the max_hw_sector limit that is entirely
>>>> + * controlled by the driver, usually based on hardware limits.
>>>> + */
>>>> +#define BLK_DEF_MAX_SECTORS_CAP    2560u
>>>> +
>>>>   static inline struct queue_limits *bdev_limits(struct 
>>>> block_device *bdev)
>>>>   {
>>>>       return &bdev_get_queue(bdev)->limits;
>>>
>>> Rejected for the following reasons:
>>>
>>> - Missing cover letter, patch number, you can refer to the following 
>>> doc:
>>>
>>> https://ubuntu.com/kernel/docs/reference/stable-patch-format/#sending-as-a-patch-series 
>>>
>>>
>>> here are some examples:
>>> https://lists.ubuntu.com/archives/kernel-team/2026-July/169687.html
>>> https://lists.ubuntu.com/archives/kernel-team/2025-September/163055.html 
>>>
>>>
>>>
>>> Rickey Castillo
>>
>




More information about the kernel-team mailing list