All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xing Zhengjun <zhengjun.xing@linux.intel.com>
To: lkp@lists.01.org
Subject: Re: [workqueue] d5bff968ea: WARNING:at_kernel/workqueue.c:#process_one_work
Date: Fri, 29 Jan 2021 14:20:18 +0800	[thread overview]
Message-ID: <bfb8370e-43e4-7f72-a71f-8481eb66f6ed@linux.intel.com> (raw)
In-Reply-To: <20210128180821.GA24510@paulmck-ThinkPad-P72>

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]



On 1/29/2021 2:08 AM, Paul E. McKenney wrote:
> 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
> 
I test mainline v5.11-rc5, it has no issue. The issue is only for 
d5bff968ea which is in 
https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git 
dev.2021.01.11b.

-- 
Zhengjun Xing

WARNING: multiple messages have this Message-ID (diff)
From: Xing Zhengjun <zhengjun.xing@linux.intel.com>
To: paulmck@kernel.org, Hillf Danton <hdanton@sina.com>
Cc: Oliver Sang <oliver.sang@intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Lai Jiangshan <laijs@linux.alibaba.com>,
	LKML <linux-kernel@vger.kernel.org>,
	lkp@intel.com, lkp <lkp@lists.01.org>
Subject: Re: [workqueue] d5bff968ea: WARNING:at_kernel/workqueue.c:#process_one_work
Date: Fri, 29 Jan 2021 14:20:18 +0800	[thread overview]
Message-ID: <bfb8370e-43e4-7f72-a71f-8481eb66f6ed@linux.intel.com> (raw)
In-Reply-To: <20210128180821.GA24510@paulmck-ThinkPad-P72>



On 1/29/2021 2:08 AM, Paul E. McKenney wrote:
> 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
> 
I test mainline v5.11-rc5, it has no issue. The issue is only for 
d5bff968ea which is in 
https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git 
dev.2021.01.11b.

-- 
Zhengjun Xing

  reply	other threads:[~2021-01-29  6:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210126073925.1962-1-hdanton@sina.com>
2021-01-27  8:04 ` [workqueue] d5bff968ea: WARNING:at_kernel/workqueue.c:#process_one_work Xing Zhengjun
2021-01-27  8:04   ` Xing Zhengjun
     [not found] ` <20210127092128.2299-1-hdanton@sina.com>
2021-01-28  7:52   ` Xing Zhengjun
2021-01-28  7:52     ` Xing Zhengjun
     [not found]   ` <20210128090905.1596-1-hdanton@sina.com>
2021-01-28 18:08     ` Paul E. McKenney
2021-01-29  6:20       ` Xing Zhengjun [this message]
2021-01-29  6:20         ` Xing Zhengjun
2021-01-29 15:11         ` Paul E. McKenney
     [not found] <20210125092900.1839-1-hdanton@sina.com>
2021-01-26  2:45 ` Xing Zhengjun
2021-01-26  2:45   ` Xing Zhengjun
     [not found] <20210122075903.1722-1-hdanton@sina.com>
2021-01-25  8:37 ` Xing Zhengjun
2021-01-25  8:37   ` Xing Zhengjun
     [not found] <20210114084248.1819-1-hdanton@sina.com>
2021-01-20 13:41 ` Oliver Sang
2021-01-20 13:41   ` Oliver Sang
2021-01-14  7:45 kernel test robot
2021-01-14  7:45 ` kernel test robot
     [not found] ` <20210115072432.150-1-hdanton@sina.com>
2021-01-20 13:46   ` Oliver Sang
2021-01-20 13:46     ` Oliver Sang
     [not found]   ` <20210121040037.1555-1-hdanton@sina.com>
2021-01-22  1:48     ` Xing Zhengjun

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=bfb8370e-43e4-7f72-a71f-8481eb66f6ed@linux.intel.com \
    --to=zhengjun.xing@linux.intel.com \
    --cc=lkp@lists.01.org \
    /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: link
Be 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.