Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH for-5.14/block] blkcg: drop CLONE_IO check in
 blkcg_can_attach()
To:     Tejun Heo <tj@kernel.org>
Cc:     linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
        Pavel Begunkov <asml.silence@gmail.com>
References: <YJrTvHbrRDbJjw+S@slm.duckdns.org>
From:   Jens Axboe <axboe@kernel.dk>
Message-ID: <6f89d141-fc55-a41e-4783-649fbd7e34ee@kernel.dk>
Date:   Tue, 11 May 2021 13:39:07 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <YJrTvHbrRDbJjw+S@slm.duckdns.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 5/11/21 12:58 PM, Tejun Heo wrote:
> 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().

Applied, thanks.

-- 
Jens Axboe