Re: [RFC PATCH 01/12] workqueue: Add interface to teach lockdep to warn on reclaim violations

[Tejun Heo <tj@kernel.org>]

Hello,

On Wed, Mar 25, 2026 at 06:49:59PM -0700, Matthew Brost wrote:
> On Wed, Mar 25, 2026 at 05:59:54AM -1000, Tejun Heo wrote:
> > Sorry about the tardiness. Traveling during spring break. Getting more than
> > I can catch up with each day.
> > 
> > On Sun, Mar 15, 2026 at 09:32:44PM -0700, Matthew Brost wrote:
> > > @@ -403,6 +403,7 @@ enum wq_flags {
> > >  	 */
> > >  	WQ_POWER_EFFICIENT	= 1 << 7,
> > >  	WQ_PERCPU		= 1 << 8, /* bound to a specific cpu */
> > > +	WQ_MEM_WARN_ON_RECLAIM	= 1 << 9, /* teach lockdep to warn on reclaim */
> > 
> > Shouldn't this require WQ_MEM_RECLAIM?
> 
> Yes, so what is suggestion here? If WQ_MEM_WARN_ON_RECLAIM is set
> without WQ_MEM_RECLAIM fail the WQ creation with -EINVAL?

Yes.

> > Why is this function necessary? It feels rather odd to use wq as the source
> > of this information. Shouldn't that be an innate knowledge of the code
> > that's using this?
> 
> This, for example, would be used in DRM sched (the existing scheduler)
> or DRM dep (the proposed replacement) to ensure that driver-allocated
> WQs passed into the layers are created with these flags. DRM sched or
> DRM dep has strict DMA-fencing, thus reclaim rule that we expect DRM
> drivers to follow. Historically, DRM drivers have broken these rules
> quite often, and we no longer want to give them the opportunity to do
> so—lockdep should enforce them.

I see. Yeah, that makes sense. Please feel free to add

 Acked-by: Tejun Heo <tj@kernel.org>

Please let me know how you wanna route the patch.

Thanks.

-- 
tejun