On Tue, Oct 21, 2025 at 03:51:08PM -1000, Tejun Heo wrote: > On Tue, Oct 21, 2025 at 06:22:19PM -0700, Matthew Brost wrote: > > > please update the patch so that WQ_MEM_RECLAIM implicitly enables the > > > checking? > > > > Sure, but a bunch of things immediately break—including a convoluted > > case in my driver. I can fix the kernel to the extent that my CI catches > > issues, and fix any obvious cases through manual inspection. However, > > I suspect that if we merge this, we'll be dealing with fallout > > throughout a kernel RC cycle. > > Sure, we're still early in this cycle and can try to resolve as much as > possible and if there's just too much, we can make it optional and so on. >
I’ve come to the conclusion that the entire kernel is going to explode if all WQ_MEM_RECLAIM workqueues are annotated with lockdep. I made this change and tried booting Linux, but quickly ran into five issues before giving up. It seems that many parts of the kernel allocate memory with GFP_KERNEL or take locks that allocate memory in workqueues marked with WQ_MEM_RECLAIM. There are literally hundreds of workqueues created with WQ_MEM_RECLAIM, both directly [1] and via the create*workqueue helpers, which also set this flag. So, what’s your advice here? Personally, I don’t have the bandwidth to drive fixing the entire kernel. Maybe we could add the annotation helpers introduced in this series, so drivers that really want to enforce this rule—like the DRM driver—can opt in? And perhaps we could add a export Kconfig option that enables this for all WQ_MEM_RECLAIM workqueues, and let the community gradually enable it and start fixing their code? Matt [1] https://elixir.bootlin.com/linux/v6.17.5/C/ident/WQ_MEM_RECLAIM > Thanks. > > -- > tejun
