From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932832AbbLCJeN (ORCPT ); Thu, 3 Dec 2015 04:34:13 -0500 Received: from casper.infradead.org ([85.118.1.10]:52404 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757678AbbLCJdz (ORCPT ); Thu, 3 Dec 2015 04:33:55 -0500 Date: Thu, 3 Dec 2015 10:33:50 +0100 From: Peter Zijlstra To: Tejun Heo Cc: Ulrich Obergfell , Ingo Molnar , Andrew Morton , linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH 1/2] watchdog: introduce touch_softlockup_watchdog_sched() Message-ID: <20151203093350.GP17308@twins.programming.kicks-ass.net> References: <20151203002810.GJ19878@mtj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151203002810.GJ19878@mtj.duckdns.org> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 02, 2015 at 07:28:10PM -0500, Tejun Heo wrote: > Hello, > > There haven't been too many workqueue stall bugs; however, good part > of them have been pretty painful to track down because there's no > lockup detection mechanism for workqueue and it isn't easy to tell > what's going on with workqueues; furthermore, some requirements are > tricky to get right - e.g. it's not too difficult to miss > WQ_MEM_RECLAIM for a workqueue which runs a work item which is flushed > by something which sits in the reclaim path. have you considered something as simple as: WARN_ON(current->reclaim_state && !WQ_MEM_RECLAIM); ?