On Thu, Dec 03, 2015 at 10:33:50AM +0100, Peter Zijlstra wrote: > 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); > > ?
Alternatively, you can 'abuse' the lockdep reclaim bits by marking !MEM_RECLAIM workqueue 'locks' with lockdep_trace_alloc(GFP_KERNEL), that way lockdep will yell if they get used in a reclaim context. This might be a tad tricky in that you need 2 sets of (lockdep) keys for things. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
