On Thu, May 23, 2024 at 10:27:31AM +0200, Christoph Hellwig wrote: > On Wed, May 22, 2024 at 12:48:59PM -0400, Mike Snitzer wrote: > > [ 74.872485] blk_insert_cloned_request: over max size limit. (2048 > 1024) > > [ 74.872505] device-mapper: multipath: 254:3: Failing path 8:16. > > [ 74.872620] blk_insert_cloned_request: over max size limit. (2048 > 1024) > > [ 74.872641] device-mapper: multipath: 254:3: Failing path 8:32. > > [ 74.872712] blk_insert_cloned_request: over max size limit. (2048 > 1024) > > [ 74.872732] device-mapper: multipath: 254:3: Failing path 8:48. > > [ 74.872788] blk_insert_cloned_request: over max size limit. (2048 > 1024) > > [ 74.872808] device-mapper: multipath: 254:3: Failing path 8:64. > > > > Simply setting max_user_sectors won't help with stacked devices > > because blk_stack_limits() doesn't stack max_user_sectors. It'll > > inform the underlying device's blk_validate_limits() calculation which > > will result in max_sectors having the desired value (which it already > > did, as I showed above). But when stacking limits from underlying > > devices up to the higher-level dm-mpath queue_limits we still have > > information loss. > > So while I can't reproduce it, I think the main issue is that > max_sectors really just is a voluntary limit, and enforcing that at > the lower device doesn't really make any sense. So we could just > check blk_insert_cloned_request to check max_hw_sectors instead. I haven't tried your patch but we still want properly stacked max_sectors configured for the device. > Or my below preferre variant to just drop the check, as the > max_sectors == 0 check indicates it's pretty sketchy to start with. At this point in the 6.10 release I don't want further whack-a-mole fixes due to fallout from removing longstanding negative checks. Not sure what is sketchy about the max_sectors == 0 check, the large comment block explains that check quite well. We want to avoid EIO for unsupported operations (otherwise we'll get spurious path failures in the context of dm-multipath). Could be we can remove this check after an audit of how LLD handle servicing IO for unsupported operations -- so best to work through it during a devel cycle. Not sure why scsi_debug based testing with mptest isn't triggering it for you. Are you seeing these limits for the underlying scsi_debug devices? ./max_hw_sectors_kb:2147483647 ./max_sectors_kb:512 What are those limits for the mptest created 'mp' dm-multipath device? Mike
