From: Tejun Heo <tj@kernel.org>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: hch@infradead.org, josef@toxicpanda.com, axboe@kernel.dk,
cgroups@vger.kernel.org, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, yi.zhang@huawei.com,
"yukuai (C)" <yukuai3@huawei.com>
Subject: Re: [PATCH -next 0/4] blk-cgroup: synchronize del_gendisk() with configuring cgroup policy
Date: Tue, 20 Dec 2022 06:01:30 -1000 [thread overview]
Message-ID: <Y6HcWiJbaWjN3jlt@slm.duckdns.org> (raw)
In-Reply-To: <e01daffe-a3e3-8bf2-40ee-192a9e70d911@huaweicloud.com>
Hello,
On Tue, Dec 20, 2022 at 05:19:12PM +0800, Yu Kuai wrote:
> Yes, that sounds good. BTW, queue_lock is also used to protect
> pd_alloc_fn/pd_init_fn,and we found that blkcg_activate_policy() is
> problematic:
>
> blkcg_activate_policy
> spin_lock_irq(&q->queue_lock);
> list_for_each_entry_reverse(blkg, &q->blkg_list
> pd_alloc_fn(GFP_NOWAIT | __GFP_NOWARN,...) -> failed
>
> spin_unlock_irq(&q->queue_lock);
> // release queue_lock here is problematic, this will cause
> pd_offline_fn called without pd_init_fn.
> pd_alloc_fn(__GFP_NOWARN,...)
So, if a blkg is destroyed while a policy is being activated, right?
> If we are using a mutex to protect rq_qos ops, it seems the right thing
> to do do also using the mutex to protect blkcg_policy ops, and this
> problem can be fixed because mutex can be held to alloc memroy with
> GFP_KERNEL. What do you think?
One worry is that switching to mutex can be more headache due to destroy
path synchronization. Another approach would be using a per-blkg flag to
track whether a blkg has been initialized.
Thanks.
--
tejun
next prev parent reply other threads:[~2022-12-20 16:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-17 3:09 Yu Kuai
2022-12-17 3:09 ` [PATCH -next 1/4] block/rq_qos: protect 'q->rq_qos' with queue_lock in rq_qos_exit() Yu Kuai
2022-12-21 10:34 ` Christoph Hellwig
2022-12-17 3:09 ` [PATCH -next 2/4] block/rq_qos: fail rq_qos_add() after del_gendisk() Yu Kuai
2022-12-17 3:09 ` [PATCH -next 3/4] blk-cgroup: add a new interface blkcg_conf_close_bdev() Yu Kuai
2022-12-17 3:09 ` [PATCH -next 4/4] blk-cgroup: synchronize del_gendisk() with configuring cgroup policy Yu Kuai
2022-12-19 20:55 ` [PATCH -next 0/4] " Tejun Heo
2022-12-20 9:19 ` Yu Kuai
2022-12-20 16:01 ` Tejun Heo [this message]
2022-12-21 1:10 ` Yu Kuai
2022-12-21 2:48 ` Yu Kuai
2022-12-21 10:37 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y6HcWiJbaWjN3jlt@slm.duckdns.org \
--to=tj@kernel.org \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=hch@infradead.org \
--cc=josef@toxicpanda.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yi.zhang@huawei.com \
--cc=yukuai1@huaweicloud.com \
--cc=yukuai3@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome