On 4/10/19 2:38 AM, Paolo Valente wrote:
> The function bfq_bfqq_expire() invokes the function
> __bfq_bfqq_expire(), and the latter may free the in-service bfq-queue.
> If this happens, then no other instruction of bfq_bfqq_expire() must
> be executed, or a use-after-free will occur.
>
> Basing on the assumption that __bfq_bfqq_expire() invokes
> bfq_put_queue() on the in-service bfq-queue exactly once, the queue is
> assumed to be freed if its refcounter is equal to one right before
> invoking __bfq_bfqq_expire().
>
> But, since commit 9dee8b3b057e ("block, bfq: fix queue removal from
> weights tree") this assumption is false. __bfq_bfqq_expire() may also
> invoke bfq_weights_tree_remove() and, since commit 9dee8b3b057e
> ("block, bfq: fix queue removal from weights tree"), also
> the latter function may invoke bfq_put_queue(). So __bfq_bfqq_expire()
> may invoke bfq_put_queue() twice, and this is the actual case where
> the in-service queue may happen to be freed.
>
> To address this issue, this commit moves the check on the refcounter
> of the queue right around the last bfq_put_queue() that may be invoked
> on the queue.
Applied, thanks.
--
Jens Axboe
