On Fri, Feb 17 2023 at 11:16P -0500, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Thu, Feb 16, 2023 at 12:27:02PM -0700, Uday Shankar wrote: > > * Description: > > * @rq may have been made based on weaker limitations of upper-level queues > > * in request stacking drivers, and it may violate the limitation of @q. > > * Since the block layer and the underlying device driver trust @rq > > * after it is inserted to @q, it should be checked against @q before > > * the insertion using this generic function. > > * > > * Request stacking drivers like request-based dm may change the queue > > * limits when retrying requests on other queues. Those requests need > > * to be checked against the new queue limits again during dispatch. > > */. > > > > Is this concern no longer relevant? > > The concern is still valid, but it does not refer to the debug check. > It refers to recalculating nr_phys_segments using > blk_recalc_rq_segments, and the fact that any driver using this > interface needs to stack its limits properly. It is a negative check that you're calling a debug check. Much easier to address a bug in a driver when seeing this message than figuring it out after more elaborate hunting. Not seeing the downside of preserving/fixing given it is a quick limit check. *shrug*
