On 2/21/23 6:07?PM, Linus Torvalds wrote:
> 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.
Yep I'm being dense, you're totally right and your merge is the right
one.
--
Jens Axboe
