Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220705123705.764-1-xuewen.yan@unisoc.com> <20220711174629.uehfmqegcwn2lqzu@wubuntu>
 <YsyO9GM9mCydaybo@slm.duckdns.org> <c1426573-92a7-9f0d-a6b8-aa612248b9a9@redhat.com>
 <Ys41ZF5TmSnLLNRB@slm.duckdns.org> <CAB8ipk-8cbur-m733py-cw4bXCt7gkd8gAOXtKO+-fV1B2EeZw@mail.gmail.com>
 <YuGbYCfAG81mZBnN@slm.duckdns.org> <CAB8ipk_gCLtvEahsp2DvPJf4NxRsM8WCYmmH=yTd7zQE+81_Yg@mail.gmail.com>
 <20220729083949.6uaojl3vqyvwpkuk@wubuntu> <YuQ8FWtrMsgDmGAr@slm.duckdns.org>
In-Reply-To: <YuQ8FWtrMsgDmGAr@slm.duckdns.org>
From:   Xuewen Yan <xuewen.yan94@gmail.com>
Date:   Tue, 9 Aug 2022 10:02:44 +0800
Message-ID: <CAB8ipk-72V-bYRfL-VcSRSyXTeQqkBVj+1d5MHSVV5CTar9a0Q@mail.gmail.com>
Subject: Re: [PATCH] sched/schedutil: Fix deadlock between cpuset and cpu
 hotplug when using schedutil
To:     Tejun Heo <tj@kernel.org>
Cc:     Qais Yousef <qais.yousef@arm.com>,
        Waiman Long <longman@redhat.com>,
        Xuewen Yan <xuewen.yan@unisoc.com>, rafael@kernel.org,
        viresh.kumar@linaro.org, mingo@redhat.com, peterz@infradead.org,
        juri.lelli@redhat.com, vincent.guittot@linaro.org,
        dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com,
        mgorman@suse.de, bristot@redhat.com, linux-kernel@vger.kernel.org,
        ke.wang@unisoc.com, xuewyan@foxmail.com, linux-pm@vger.kernel.org,
        Lukasz Luba <Lukasz.Luba@arm.com>, pengcheng.lai@unisoc.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Tejun

On Sat, Jul 30, 2022 at 3:59 AM Tejun Heo <tj@kernel.org> wrote:
>
> On Fri, Jul 29, 2022 at 09:39:49AM +0100, Qais Yousef wrote:
> > I *think* it's because we haven't removed cpus_read_lock() from
> > cpuset_attach(). So we end up holding the lock twice in the same path. Since we
> > hold it unconditionally now, we should remove cpuset dependency on
> > cpus_read_lock() I believe.
>
> Ah, yeah, that's because pending write locker makes future reader lockers
> wait, so even if we're holding read lock, if we try to read lock again, we
> end up waiting. I'll make the cpus_read_lock() unconditional in cgroup core
> and drop it from cpuset's attach operation.

I revert the following patch which add the cpus_read_lock() in
cpuset's attach and have test for a while. And the deadlock has not
reproduced.

https://lore.kernel.org/all/20220121101210.84926-1-zhangqiao22@huawei.com/

But I do not know the risk with reverting the patch..

Thanks!
BR
-- 
xuewen

>
> Thanks.
>
> --
> tejun