From: Tejun Heo <tj@kernel.org>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Steven Rostedt <rostedt@goodmis.org>
Cc: jiangshanlai@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: WARN_ON_ONCE() in process_one_work()?
Date: Mon, 1 May 2017 14:42:50 -0400 [thread overview]
Message-ID: <20170501184250.GA8921@htj.duckdns.org> (raw)
In-Reply-To: <20170501165747.GA993@linux.vnet.ibm.com>
Hello, Paul.
Hmmm... Steven reproted a similar issue.
http://lkml.kernel.org/r/20170405151628.33df783f@gandalf.local.home
On Mon, May 01, 2017 at 09:57:47AM -0700, Paul E. McKenney wrote:
> Hello!
>
> I am hitting this WARN_ON_ONCE() in process_one_work() and am wondering
> what I did wrong to make this happen:
>
> ------------------------------------------------------------------------
>
> static void process_one_work(struct worker *worker, struct work_struct *work)
> __releases(&pool->lock)
> __acquires(&pool->lock)
> {
> struct pool_workqueue *pwq = get_work_pwq(work);
> struct worker_pool *pool = worker->pool;
> bool cpu_intensive = pwq->wq->flags & WQ_CPU_INTENSIVE;
> int work_color;
> struct worker *collision;
> #ifdef CONFIG_LOCKDEP
> /*
> * It is permissible to free the struct work_struct from
> * inside the function that is called from it, this we need to
> * take into account for lockdep too. To avoid bogus "held
> * lock freed" warnings as well as problems when looking into
> * work->lockdep_map, make a copy and use that here.
> */
> struct lockdep_map lockdep_map;
>
> lockdep_copy_map(&lockdep_map, &work->lockdep_map);
> #endif
> /* ensure we're on the correct CPU */
> WARN_ON_ONCE(!(pool->flags & POOL_DISASSOCIATED) &&
> raw_smp_processor_id() != pool->cpu);
>
> ------------------------------------------------------------------------
>
> Here is the splat:
>
> ------------------------------------------------------------------------
>
> [12600.593006] WARNING: CPU: 0 PID: 6 at /home/paulmck/public_git/linux-rcu/kernel/workqueue.c:2041 process_one_work+0x46c/0x4d0
> [12600.593006] Modules linked in:
> [12600.593006] CPU: 0 PID: 6 Comm: mm_percpu_wq Not tainted 4.11.0-rc7+ #1
> [12600.593006] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
> [12600.593006] Call Trace:
> [12600.593006] dump_stack+0x4f/0x72
> [12600.593006] __warn+0xc6/0xe0
> [12600.593006] warn_slowpath_null+0x18/0x20
> [12600.593006] process_one_work+0x46c/0x4d0
> [12600.593006] rescuer_thread+0x20e/0x3b0
> [12600.593006] kthread+0x104/0x140
> [12600.593006] ? worker_thread+0x4e0/0x4e0
> [12600.593006] ? kthread_create_on_node+0x40/0x40
> [12600.593006] ret_from_fork+0x29/0x40
>
> ------------------------------------------------------------------------
>
> This happens about 3.5 hours into the TREE03 rcutorture scenario, .config
> attached.
Steven's involved a rescuer too. One possibility was cpuset being
involved somehow and messing up the affinity of the rescuer kthread
unexpectedly. Is cpuset involved in any way?
Thanks.
--
tejun
next prev parent reply other threads:[~2017-05-01 18:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-01 16:57 WARN_ON_ONCE() in process_one_work()? Paul E. McKenney
2017-05-01 18:38 ` Paul E. McKenney
2017-05-01 18:44 ` Tejun Heo
2017-05-01 18:58 ` Paul E. McKenney
2017-05-05 17:11 ` Paul E. McKenney
2017-06-13 20:58 ` Tejun Heo
2017-06-13 22:31 ` Paul E. McKenney
2017-06-14 15:15 ` Paul E. McKenney
2017-06-15 15:38 ` Paul E. McKenney
2017-06-16 17:36 ` Paul E. McKenney
2017-06-17 11:53 ` Tejun Heo
2017-06-17 17:31 ` Paul E. McKenney
2017-06-18 10:40 ` Tejun Heo
2017-06-20 16:45 ` Paul E. McKenney
2017-06-21 15:30 ` Paul E. McKenney
2017-06-23 16:41 ` Paul E. McKenney
2017-06-27 16:27 ` Paul E. McKenney
2017-05-01 18:42 ` Tejun Heo [this message]
2017-05-01 19:42 ` Steven Rostedt
2017-05-01 19:50 ` Tejun Heo
2017-05-01 20:02 ` Steven Rostedt
2018-06-20 19:29 Paul E. McKenney
2018-07-02 21:05 ` Tejun Heo
2018-07-03 4:05 ` Paul E. McKenney
2018-07-03 16:40 ` Paul E. McKenney
2018-07-03 20:12 ` Tejun Heo
2018-07-03 21:44 ` Paul E. McKenney
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=20170501184250.GA8921@htj.duckdns.org \
--to=tj@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rostedt@goodmis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).