From: "yukuai (C)" <yukuai3@huawei.com> To: "Michal Koutný" <mkoutny@suse.com> Cc: <hch@infradead.org>, <tj@kernel.org>, <axboe@kernel.dk>, <cgroups@vger.kernel.org>, <linux-block@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <yi.zhang@huawei.com> Subject: Re: [PATCH v4 2/2] block: cancel all throttled bios in del_gendisk() Date: Sat, 4 Dec 2021 16:03:53 +0800 [thread overview] Message-ID: <c8a16fe9-4ad2-682d-0d34-1049dc217d62@huawei.com> (raw) In-Reply-To: <20211203102739.GB64349@blackbody.suse.cz> 在 2021/12/03 18:27, Michal Koutný 写道: > On Fri, Dec 03, 2021 at 03:50:01PM +0800, "yukuai (C)" <yukuai3@huawei.com> wrote: >> blkg_destroy() is protected by the queue_lock,so I think queue_lock can >> protect such concurrent scenario. > > blkg_destroy() is not as destroying :-) as actual free, you should > synchronize against (the queue_lock ensures this for > pd_free_fn=throtl_pd_free but you may still trip on blkcg after > blkcg_css_free()). Hi, Michal I was thinking that if there are active blkgs, holding queue_lock will ensure blkcg won't be freed. However, if there are no active blkgs in the first place, it seems right rcu_read_lock() can prevent this iteration concurrent with css_release->css_release_work_fn-> css_free_rwork_fn. By the way, does spin_lock can guarantee this since it disables preempt like what rcu_read_lock() does? Thanks, Kuai > > [Actually, I think you should see a warning in your situation if you > enable CONFIG_PROVE_RCU.] > > HTH, > Michal >
WARNING: multiple messages have this Message-ID (diff)
From: "yukuai (C)" <yukuai3@huawei.com> To: "Michal Koutný" <mkoutny@suse.com> Cc: hch@infradead.org, tj@kernel.org, axboe@kernel.dk, cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, yi.zhang@huawei.com Subject: Re: [PATCH v4 2/2] block: cancel all throttled bios in del_gendisk() Date: Sat, 4 Dec 2021 16:03:53 +0800 [thread overview] Message-ID: <c8a16fe9-4ad2-682d-0d34-1049dc217d62@huawei.com> (raw) In-Reply-To: <20211203102739.GB64349@blackbody.suse.cz> 在 2021/12/03 18:27, Michal Koutný 写道: > On Fri, Dec 03, 2021 at 03:50:01PM +0800, "yukuai (C)" <yukuai3@huawei.com> wrote: >> blkg_destroy() is protected by the queue_lock,so I think queue_lock can >> protect such concurrent scenario. > > blkg_destroy() is not as destroying :-) as actual free, you should > synchronize against (the queue_lock ensures this for > pd_free_fn=throtl_pd_free but you may still trip on blkcg after > blkcg_css_free()). Hi, Michal I was thinking that if there are active blkgs, holding queue_lock will ensure blkcg won't be freed. However, if there are no active blkgs in the first place, it seems right rcu_read_lock() can prevent this iteration concurrent with css_release->css_release_work_fn-> css_free_rwork_fn. By the way, does spin_lock can guarantee this since it disables preempt like what rcu_read_lock() does? Thanks, Kuai > > [Actually, I think you should see a warning in your situation if you > enable CONFIG_PROVE_RCU.] > > HTH, > Michal >
next prev parent reply other threads:[~2021-12-04 8:03 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-12-02 13:04 [PATCH v4 0/2] cancel all throttled bios in del_gendisk() Yu Kuai 2021-12-02 13:04 ` Yu Kuai 2021-12-02 13:04 ` [PATCH v4 1/2] blk-throtl: move WARN_ON_ONCE() from throtl_rb_first() to it's caller Yu Kuai 2021-12-02 13:04 ` Yu Kuai 2021-12-02 13:04 ` [PATCH v4 2/2] block: cancel all throttled bios in del_gendisk() Yu Kuai 2021-12-02 13:04 ` Yu Kuai 2021-12-02 14:48 ` Michal Koutný 2021-12-02 14:48 ` Michal Koutný 2021-12-03 7:50 ` yukuai (C) 2021-12-03 7:50 ` yukuai (C) 2021-12-03 10:27 ` Michal Koutný 2021-12-03 10:27 ` Michal Koutný 2021-12-04 8:03 ` yukuai (C) [this message] 2021-12-04 8:03 ` yukuai (C) 2021-12-06 15:43 ` Michal Koutný 2021-12-06 15:43 ` Michal Koutný
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=c8a16fe9-4ad2-682d-0d34-1049dc217d62@huawei.com \ --to=yukuai3@huawei.com \ --cc=axboe@kernel.dk \ --cc=cgroups@vger.kernel.org \ --cc=hch@infradead.org \ --cc=linux-block@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mkoutny@suse.com \ --cc=tj@kernel.org \ --cc=yi.zhang@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.