Re: v4.20-rc6: Sporadic use-after-free in bt_iter()

[Evan Green <evgreen@google.com>]

Hi Jens,
I got all turned around while trying to understand this fix, and I'll
admit it's probably just me. It looks like you're trying to use an rcu
lock to prevent the iter functions from racing with free. Is that
true? But then the race at least as I understand it wasn't that there
was a free in-flight, it's that the free had happened a long time ago,
and there was still a stale value in tags->rqs[bitnr]. So maybe
there's some other issue that part is solving?

And then it looks like you added a new struct where tags->rqs was so
that you could compare hctx->queue without reaching through rq. I have
no idea if that's sufficient to prevent stale accesses through rq.
Since you're changing multiple values I think where you populate that
structure you'd at least need to do something like: clear rq, barrier,
set hctx, barrier, set rq. But like Bart said, that's probably not the
right way to go.

Finally, I didn't really get why the conditional in
blk_mq_rq_inflight() changed. Is that guarding against some other
identified problem, or just an additional check you can do when you
convert rqs into a struct?

It looks like blk_mq_free_rqs() might be the magic function I was
looking for earlier. Would it be possible to just clear tags[rq->tag]
for each static_rq? Or is it possible for rqs from one set to end up
in the tags array of another set? (Which would make what I just
suggested insufficient).
-Evan