From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752415AbdDKAIy (ORCPT ); Mon, 10 Apr 2017 20:08:54 -0400 Received: from mail-ua0-f196.google.com ([209.85.217.196]:35543 "EHLO mail-ua0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751685AbdDKAIw (ORCPT ); Mon, 10 Apr 2017 20:08:52 -0400 Date: Tue, 11 Apr 2017 09:08:37 +0900 From: Tejun Heo To: Steven Rostedt Cc: LKML Subject: Re: [WARNING] kernel/workqueue.c:2041 process_one_work (when cpu goes offline) Message-ID: <20170411000837.GA29406@wtj.duckdns.org> References: <20170405151628.33df783f@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170405151628.33df783f@gandalf.local.home> User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Steven. On Wed, Apr 05, 2017 at 03:16:28PM -0400, Steven Rostedt wrote: > 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? If this happens while CPU is going donw, the pool should have POOL_DISASSOCIATED set by that point and the actual affinity shouldn't matter. Maybe I messed up the rescuer part of it. I'll look into it. Thanks. -- tejun