On Thu, May 23, 2024 at 05:44:35PM +0200, Christoph Hellwig wrote: > On Thu, May 23, 2024 at 11:38:21AM -0400, Mike Snitzer wrote: > > Sure, we could elevate it to blk_validate_limits (and callers) but > > adding a 'stacking' parameter is more intrusive on an API level. > > > > Best to just update blk_set_stacking_limits() to set a new 'stacking' > > flag in struct queue_limits, and update blk_stack_limits() to stack > > that flag up. > > > > I've verified this commit to work and have staged it in linux-next via > > linux-dm.git's 'for-next', see: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=cedc03d697ff255dd5b600146521434e2e921815 > > > > Jens (and obviously: Christoph, Ming and others), I'm happy to send > > this to Linus tomorrow morning if you could please provide your > > Reviewed-by or Acked-by. I'd prefer to keep the intermediate DM fix > > just to "show the work and testing". > > A stacking flag in the limits is fundamentally wrong, please don't > do this. Um, how so? It serves as a hint to how the limits were constructed. 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. Happy to see the need for the 'stacking' flag to go away in time but I fail to see why it is "fundamentally wrong". Mike
