[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210128180821.GA24510@paulmck-ThinkPad-P72>
Date: Thu, 28 Jan 2021 10:08:21 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Hillf Danton <hdanton@...a.com>
Cc: Xing Zhengjun <zhengjun.xing@...ux.intel.com>,
Oliver Sang <oliver.sang@...el.com>,
Peter Zijlstra <peterz@...radead.org>,
Lai Jiangshan <laijs@...ux.alibaba.com>,
LKML <linux-kernel@...r.kernel.org>, lkp@...el.com
Subject: Re: [workqueue] d5bff968ea:
WARNING:at_kernel/workqueue.c:#process_one_work
On Thu, Jan 28, 2021 at 05:09:05PM +0800, Hillf Danton wrote:
> On Thu, 28 Jan 2021 15:52:40 +0800 Xing Zhengjun wrote:
[ . . . ]
> >I test the patch 4 times, no warning appears in the kernel log.
>
> Thank you so much Zhengjun!
>
> And the overall brain dump so far is
>
> 1/ before and after d5bff968ea, changing the allowed ptr at online time
> is the key to quiesce the warning in process_one_work().
>
> 2/ marking pcpu before changing aptr in rebind_workers() is mandatory in
> regards to cutting the risk of triggering such a warning.
>
> 3/ we canot maintain such an order without quiescing the 508 warning for
> kworkers. And we have a couple of excuses to do so, a) the number of
> allowed CPUs is no longer checked in is_per_cpu_kthread() instead of
> PF_NO_SETAFFINITY, b) there is always a followup act to change the aptr
> in order to fix the number of aCPUs.
>
> 4/ same order is maintained also at rescue time.
Just out of curiosity, does this test still fail on current mainline?
Thanx, Paul
Powered by blists - more mailing lists