linux-kernel - [WARNING] kernel/workqueue.c:2041 process_one

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 5 Apr 2017 15:16:28 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Tejun Heo <tj@...nel.org>
Cc:     LKML <linux-kernel@...r.kernel.org>
Subject: [WARNING] kernel/workqueue.c:2041 process_one_work (when cpu goes
 offline)

Hi Tejun,

My tests have started to recently trigger this warning quite often,
which causes my tests to fail. The test that triggers this is running
the mmiotracer which forces all but one CPU offline.

------------[ cut here ]------------
WARNING: CPU: 0 PID: 6 at /work/autotest/nobackup/linux-test.git/kernel/workqueue.c:2041 process_one_work+0x90/0x485
Modules linked in: ppdev parport_pc parport [last unloaded: trace_events_sample]
CPU: 0 PID: 6 Comm: vmstat Not tainted 4.11.0-rc5-test+ #3
Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014
Call Trace:
 dump_stack+0x68/0x92
 __warn+0xc2/0xdd
 warn_slowpath_null+0x1d/0x1f
 process_one_work+0x90/0x485
 process_scheduled_works+0x2c/0x33
 rescuer_thread+0x19c/0x295
 ? process_scheduled_works+0x33/0x33
 kthread+0xf4/0xf9
 ? __list_del_entry+0x22/0x22
 ret_from_fork+0x2e/0x40
---[ end trace ed53fc9d3ce10aa8 ]---

#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) &&   <<--- line 2041
		     raw_smp_processor_id() != pool->cpu);

	/*
	 * A single work shouldn't be executed concurrently by
	 * multiple workers on a single cpu.  Check whether anyone is
	 * already processing the work.  If so, defer the work to the
	 * currently executing one.
	 */


I'm assuming that this thread was migrated due to the CPU offlining and
causes pool->cpu not to equal raw_smp_processor_id(). Or should that
not be happening?

Thoughts?

-- Steve