[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aPgXH_JjkmKO5_a_@slm.duckdns.org>
Date: Tue, 21 Oct 2025 13:28:31 -1000
From: Tejun Heo <tj@...nel.org>
To: Matthew Brost <matthew.brost@...el.com>
Cc: intel-xe@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org, jiangshanlai@...il.com,
simona.vetter@...ll.ch, christian.koenig@....com,
pstanner@...hat.com, dakr@...nel.org
Subject: Re: [RFC PATCH 1/3] workqueue: Add an interface to taint workqueue
lockdep with reclaim
Hello,
On Tue, Oct 21, 2025 at 03:04:14PM -0700, Matthew Brost wrote:
> > Hmm... would it make sense to tie this to WQ_MEM_RECLAIM - ie. enable it
> > implicitly on workqueues w/ the flag set?
>
> I had considered this, and for a while I thought WQ_MEM_RECLAIM already
> did what I'm suggesting—especially since I’ve spotted bugs in drivers
> where I would have expected lockdep to catch them.
>
> In my opinion, this approach is better, but it has a broader kernel-wide
> scope and could potentially break some things. My subsequent patches
> will likely break one or two DRM drivers, so it might not be a concern
> to fix everything that breaks across the kernel. It's up to you which
> route we want to take here.
Yeah, it is bothersome that WQ_MEM_RECLAIM doesn't currently have a way to
ensure compliance. I just didn't know about the lockdep mechanism. Can you
please update the patch so that WQ_MEM_RECLAIM implicitly enables the
checking?
Thanks.
--
tejun
Powered by blists - more mailing lists