[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aQJE170PEFatwXCG@lstrano-desk.jf.intel.com>
Date: Wed, 29 Oct 2025 09:46:15 -0700
From: Matthew Brost <matthew.brost@...el.com>
To: Tejun Heo <tj@...nel.org>
CC: Christian König <christian.koenig@....com>,
	<intel-xe@...ts.freedesktop.org>, <dri-devel@...ts.freedesktop.org>,
	<linux-kernel@...r.kernel.org>, <jiangshanlai@...il.com>,
	<simona.vetter@...ll.ch>, <pstanner@...hat.com>, <dakr@...nel.org>
Subject: Re: [RFC PATCH 1/3] workqueue: Add an interface to taint workqueue
 lockdep with reclaim
On Wed, Oct 29, 2025 at 05:06:46AM -1000, Tejun Heo wrote:
> Hello,
> 
> On Tue, Oct 28, 2025 at 01:16:43PM -0700, Matthew Brost wrote:
> > On Tue, Oct 28, 2025 at 10:32:54AM +0100, Christian König wrote:
> > > On 10/21/25 23:39, Matthew Brost wrote:
> > > > Drivers often use workqueues that are in the reclaim path (e.g., DRM
> > > > scheduler workqueues). It is useful to teach lockdep that memory cannot
> > > > be allocated on these workqueues. Add an interface to taint workqueue
> > > > lockdep with reclaim.
> > > 
> > > Oh that is so wonderfully evil. I'm absolutely in favor of doing this.
> > > 
> > > But can't we check for the existing WQ_MEM_RECLAIM flag in the workqueue handling instead?
> > > 
> > 
> > Tejun suggested tying the lockdep annotation to WQ_MEM_RECLAIM, but the
> > entire kernel explodes because many workqueues throughout Linux don’t
> > adhere to this rule. Here's a link to my latest reply to Tejun [1].
> 
> How about making it a WQ flag?
> 
That could work too. We want to enforce rules of drivers actually set
these flags setting passing workqueues to the DRM scheduler. Any
objection to adding helpers to the workqueue layer to fish the
information we'd like to enforce?
Matt
> Thanks.
> 
> -- 
> tejun
Powered by blists - more mailing lists
 
