diff options
author | Tejun Heo <tj@kernel.org> | 2021-05-11 20:58:04 +0200 |
---|---|---|
committer | Jens Axboe <axboe@kernel.dk> | 2021-05-24 14:47:21 +0200 |
commit | b5f3352e0868611b555e1dcb2e1ffb8e346c519c (patch) | |
tree | 8de18bf3601fccf37bbcf1530818c7d0b9df3342 /block/blk-sysfs.c | |
parent | aoe: remove unnecessary mutex_init() (diff) | |
download | linux-b5f3352e0868611b555e1dcb2e1ffb8e346c519c.tar.xz linux-b5f3352e0868611b555e1dcb2e1ffb8e346c519c.zip |
blkcg: drop CLONE_IO check in blkcg_can_attach()
blkcg has always rejected to attach if any of the member tasks has shared
io_context. The rationale was that io_contexts can be shared across
different cgroups making it impossible to define what the appropriate
control behavior should be. However, this check causes more problems than it
solves:
* The check prevents controller enable and migrations but not CLONE_IO
itself, which can lead to surprises as the outcome changes depending on
the order of operations.
* Sharing within a cgroup is fine but the check can't distinguish that. This
leads to unnecessary conflicts with the recent CLONE_IO usage in io_uring.
io_context sharing doesn't make any difference for rq_qos based controllers
and the way it's used is safe as long as tasks aren't migrated dynamically
which is the vast majority of use cases. While we can try to make the check
more precise to avoid false positives, the added complexity doesn't seem
worthwhile. Let's just drop blkcg_can_attach().
Signed-off-by: Tejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/YJrTvHbrRDbJjw+S@slm.duckdns.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'block/blk-sysfs.c')
0 files changed, 0 insertions, 0 deletions