On Tue, Feb 21, 2023 at 4:03 PM Jens Axboe <axboe@xxxxxxxxx> wrote:
>
> I'll double check it. The merge doesn't end up touching any of
> bfq_sync_bfqq_move()
It absolutely does.
Or rather - your merge doesn't end up touching it, and I claim that's
exactly the problem.
My merge *does* touch it, and I think my merge is the right thing to do..
> just conflicting with:
>
> bfq_check_ioprio_change(), where the release ordering should be upheld,
That's the trivial case.
But:
> __bfq_bic_change_cgroup(), where it's still done after assigning the
> async_bfqq.
No.
That's where bfq_sync_bfqq_move() *comes* from. See commit
9778369a2d6c ("block, bfq: split sync bfq_queues on a per-actuator
basis").
The whole bfq_sync_bfqq_move() function didn't exist at all in the
tree that fixed the bfq_release_process_ref() ordering.
It was split out of the __bfq_bic_change_cgroup() code, so the change
to __bfq_bic_change_cgroup() needed to now instead be done in that
bfq_sync_bfqq_move() code.
Linus
