Hi Keith On 3/27/19 2:51 PM, Keith Busch wrote: > On Wed, Mar 27, 2019 at 10:45:33AM +0800, jianchao.wang wrote: >> 1. a hctx->fq.flush_rq of dead request_queue that shares the same tagset >> The whole request_queue is cleaned up and freed, so the hctx->fq.flush is freed back to a slab >> >> 2. a removed io scheduler's sched request >> The io scheduled is detached and all of the structures are freed, including the pages where sched >> requests locates. >> >> So the pointers in tags->rqs[] may point to memory that is not used as a blk layer request. > > Oh, free as in kfree'd, not blk_mq_free_request. So it's a read-after- > free that you're concerned about, not that anyone explicitly changed a > request->state. Yes ;) > > We at least can't free the flush_queue until the queue is frozen. If the > queue is frozen, we've completed the special fq->flush_rq where its end_io > replaces tags->rqs[tag] back to the fq->orig_rq from the static_rqs, > so nvme's iterator couldn't see the fq->flush_rq address if it's invalid. > This is true for the non io-scheduler case in which the flush_rq would steal the driver tag. But for io-scheduler case, flush_rq would acquire a driver tag itself. > The sched_tags concern, though, appears theoretically possible. > Thanks Jianchao
