On Thu, May 23, 2024 at 05:52:17PM +0200, Christoph Hellwig wrote: > On Thu, May 23, 2024 at 11:48:50AM -0400, Mike Snitzer wrote: > > > > Reality is, we have stacking block devices that regularly are _not_ > > accounted for when people make changes to block core queue_limits > > code. That is a serious problem. > > Well, maybe we need to sure blktests covers this instead of either > impossible to run on a stock distro (device_mapper tests) or always > somehow hanging (lvm2 testsuite) separate tests..
Happy to see mptest get folded into blktests (its just bash code) -- but it doesn't reproduce for you so not a reliable safeguard. The other testsuites aren't applicable to this particular issue, but I don't disagree that the unicorn automated test frameworks used for DM aren't robust enough. > > Happy to see the need for the 'stacking' flag to go away in time but I > > fail to see why it is "fundamentally wrong". > > Because stacking limits should not in any way be built different. > Both the stacking flag and your restoring of the value just hack > around the problem instead of trying to address it. Let's use a > little time to sort this out properly instead of piling up hacks. I have limited patience for queue_limits bugs given how long it took us to stablize limits stacking (and how regressions keep happening). All of the changes to render max_sectors and max_discard_sectors unsettable directly (and only allow them being set in terms of an ever growing array of overrides) were quite the big hammer. But yeah, it is what it is. I do appreciate your concern with me wanting limits stacking to be a more pronounced first-class citizen in block core's queue_limits code. I was trying to get the code back to a reliable state relative to blk_stack_limits() et al -- for any underlying driver that might also be blind to (ab)using max_user_sectors to steer blk_validate_limits(). I'm concerned such hacks are also fragile. But in general I know we share the same goal, so I'll slow down and yield to you to run with piecewise fixes where needed. Will reply to your latest patch now. Mike
