Hi,
在 2026/9/15 14:49, Christoph Hellwig 写道:
> On Sun, Sep 13, 2026 at 02:54:39PM +0800, Yu Kuai wrote:
>> @@ -6243,10 +6245,17 @@ static void bfq_insert_request(struct blk_mq_hw_ctx
>> *hctx, struct request *rq,
>> bool idle_timer_disabled = false;
>> blk_opf_t cmd_flags;
>> LIST_HEAD(free);
>>
>> #ifdef CONFIG_BFQ_GROUP_IOSCHED
>> + /*
>> + * Pin the blkg used to look up bfqg. If this is the first IO for
>> + * the blkcg on this queue, create the bfqg before holding bfqd->lock.
>> + */
>> + if (rq->bio && !bio_flagged(rq->bio, BIO_BLKG_REF))
>> + bio_blkg(rq->bio);
> Can rq->bio be NULL here? flush or empty passthrough request should
> never enter the scheuler.
Yes, rq->bio should never be NULL.
>
>> if (!cgroup_subsys_on_dfl(io_cgrp_subsys) && rq->bio)
>> bfqg_stats_update_legacy_io(q, rq);
> But I guess given that the code below checks it, we should at least
> be consistent, so I guess it is better to keep it for now.
>
>>
>> static inline void dm_bio_record(struct dm_bio_details *bd, struct bio
>> *bio)
>> {
>> bd->bi_bdev = bio->bi_bdev;
>> - bd->bi_flags = bio->bi_flags;
>> + /* Restoring an ownership bit cannot recreate the associated reference.
>> */
>> + bd->bi_flags = bio->bi_flags & ~(1U << BIO_BLKG_REF);
> I have a bit of a hard time parsing this, the line also is overly
> long.
This is an issue found by AI, if the new flag is recorded to bi_flags, and the
flag can be
restored to new bio by dm_bio_restore() without actually acquire a blkg
reference. And I
checked this is the only place to read/write bi_flags directly in driver.
--
Thanks,
Kuai
