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

Tejun Heo
2026-03-26T02:19:46Z

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