Re: [PATCHv2] blk-mq: check for stale cached request in blk_mq_submit_bio

[Ming Lei <tom.leiming@gmail.com>]

On Mon, May 18, 2026 at 09:07:22PM -0600, Keith Busch wrote:
> On Tue, May 19, 2026 at 09:24:50AM +0800, Ming Lei wrote:
> > On Fri, May 01, 2026 at 10:41:19AM -0700, Keith Busch wrote:
> > >  
> > >  new_request:
> > >  	if (rq) {
> > > -		blk_mq_use_cached_rq(rq, plug, bio);
> > > +		if (!blk_mq_use_cached_rq(rq, plug, bio)) {
> > > +			struct bio_integrity_payload *bip = bio_integrity(bio);
> > > +
> > > +			if (bip && (bip->bip_flags & BIP_BLOCK_INTEGRITY))
> > > +				bio_integrity_free(bio);
> > > +			rq = NULL;
> > > +			goto retry;
> > > +		}
> > 
> > This way still looks fragile, given rq isn't guaranteed to be live.
> 
> Yeah. The current usage in this patch looks like it should work out, but
> not necessarily by design, so yes, fragile.
>  
> > Just wondering why not pop it from plug->cached_rqs from beginning, and
> > move it back in case of `queue_exit:`?
> 
> Not sure. I guess it's an optimization when the bio merges with a
> previous request in the plug? If we popped initially, a successful merge
> has to push it back. Maybe there's a better reason I'm not seeing.

Yes, this way may avoid potential perf regression for heavy merge cases.

Thanks,
Ming