[PATCH] workqueue: Fix NULL current_pwq deref in flush dependency check

[PATCH] workqueue: Fix NULL current_pwq deref in flush dependency check

[Pavankumar Kondeti]

check_flush_dependency() uses current_wq_worker() to determine whether
the caller is a workqueue worker and then dereferences worker->current_pwq
to test whether the current workqueue is WQ_MEM_RECLAIM.

current_wq_worker() only means that %current has PF_WQ_WORKER set. A
kworker can reach check_flush_dependency() while it is not executing a
work item. One such path is worker_thread() acting as the pool manager,
where create_worker() does GFP_KERNEL allocation and the allocation path
invokes the OOM notifier. In that state worker->current_pwq is NULL
because current_pwq is set only by process_one_work() and cleared again
after the work function returns.

[  416.760634][  T375] Call trace:
[  416.760638][  T375]  check_flush_dependency+0x80/0x120 (P)
[  416.760648][  T375]  __flush_work+0x98/0x224
[  416.760657][  T375]  flush_work+0x30/0x44
[  416.760665][  T375]  ...
[  416.760710][  T375]  blocking_notifier_call_chain+0x58/0xa0
[  416.760719][  T375]  out_of_memory+0xb4/0x458
[  416.760730][  T375]  __alloc_pages_may_oom+0x11c/0x1a8
[  416.760739][  T375]  __alloc_pages_slowpath+0x314/0x46c
[  416.760746][  T375]  __alloc_frozen_pages_noprof+0x110/0x1a4
[  416.760753][  T375]  new_slab+0x12c/0x484
[  416.760759][  T375]  ___slab_alloc+0x7a8/0xc7c
[  416.760765][  T375]  __slab_alloc+0x74/0xd8
[  416.760772][  T375]  __kmalloc_cache_node_noprof+0x2ac/0x304
[  416.760779][  T375]  alloc_worker+0x28/0x60
[  416.760785][  T375]  create_worker+0x4c/0x20c
[  416.760790][  T375]  worker_thread+0xe8/0x2b8
[  416.760796][  T375]  kthread+0x1a8/0x200
[  416.760805][  T375]  ret_from_fork+0x10/0x20

Guard the WQ_MEM_RECLAIM-worker warning with worker->current_pwq. If the
kworker is not currently executing a work item, there is no current
workqueue to diagnose with that warning. The PF_MEMALLOC warning is left
unchanged so explicit reclaim context flushing a !WQ_MEM_RECLAIM target
is still reported.

Fixes: fca839c00a12 ("workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com>
---
 kernel/workqueue.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 1ae3732a2c51..959525393739 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3918,7 +3918,7 @@ static void check_flush_dependency(struct workqueue_struct *target_wq,
 	WARN_ONCE(current->flags & PF_MEMALLOC,
 		  "workqueue: PF_MEMALLOC task %d(%s) is flushing !WQ_MEM_RECLAIM %s:%ps",
 		  current->pid, current->comm, target_wq->name, target_func);
-	WARN_ONCE(worker && ((worker->current_pwq->wq->flags &
+	WARN_ONCE(worker && worker->current_pwq && ((worker->current_pwq->wq->flags &
 			      (WQ_MEM_RECLAIM | __WQ_LEGACY)) == WQ_MEM_RECLAIM),
 		  "workqueue: WQ_MEM_RECLAIM %s:%ps is flushing !WQ_MEM_RECLAIM %s:%ps",
 		  worker->current_pwq->wq->name, worker->current_func,

---
base-commit: 93f51579e7df248780214094418f205253383cc5
change-id: 20260925-wq_flush_dep_fix-11e657c0b1d3

Best regards,
-- 
Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com>

Re: [PATCH] workqueue: Fix NULL current_pwq deref in flush dependency check

[Tejun Heo]

Applied to wq/for-7.3-fixes.

- is_chained_work() has the same problem. It dereferences
  worker->current_pwq after checking only worker. It is only reached when
  queueing on a draining or destroying workqueue, but a kworker outside a
  work item would crash there the same way. Can you send a fix for that
  one too?

Thanks.

--
tejun

Re: [PATCH] workqueue: Fix NULL current_pwq deref in flush dependency check

[Pavan Kondeti]

On Sat, Sep 26, 2026 at 10:30:46PM -1000, Tejun Heo wrote:
> Applied to wq/for-7.3-fixes.
> 
> - is_chained_work() has the same problem. It dereferences
>   worker->current_pwq after checking only worker. It is only reached when
>   queueing on a draining or destroying workqueue, but a kworker outside a
>   work item would crash there the same way. Can you send a fix for that
>   one too?
> 
Thanks Tejun. I have sent the fix for is_chained_work() and CC'd stable.

I have also sent a separate fix to cover current_is_workqueue_mem_reclaim()
which is exported but there is only one user (NFS). It does not appear
to me that this can be triggered from NFS code path, so for now I did
not copy stable for this patch.

Thanks,
Pavan