diff options
| author | Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com> | 2026-09-28 09:18:56 +0530 |
|---|---|---|
| committer | Tejun Heo <tj@kernel.org> | 2026-09-28 07:46:45 -1000 |
| commit | 980db94e3eeefdd8a1c46f86412c33a7f7806f51 (patch) | |
| tree | e03ffe3767b70c43ef9c2a33179fe2c4cdf97f8e /tools/lib/python/kdoc/python_version.py | |
| parent | db6365ced4d5855e321f772b240c0e473bcfcdd5 (diff) | |
| download | linux-next-980db94e3eeefdd8a1c46f86412c33a7f7806f51.tar.gz linux-next-980db94e3eeefdd8a1c46f86412c33a7f7806f51.zip | |
workqueue: Fix NULL current_pwq deref in chained work check
current_wq_worker() only tells us that %current is a kworker. It does
not guarantee that the worker is currently executing a work item, as
worker->current_pwq is populated only while process_one_work() is running
the work function.
is_chained_work() can be reached while queueing on a draining or
destroying workqueue. If a kworker outside work-item execution reaches
that path, current_wq_worker() returns a worker but worker->current_pwq is
NULL, and the chained-work test can fault before it emits the intended
warning.
Guard the chained-work test with worker->current_pwq. A kworker without
current_pwq is not executing work on the target workqueue, so the helper
should return false and let the draining/destroying warning fire.
Fixes: 8d03ecfe4718 ("workqueue: reimplement is_chained_work() using current_wq_worker()")
Cc: stable@vger.kernel.org
Signed-off-by: Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Diffstat (limited to 'tools/lib/python/kdoc/python_version.py')
0 files changed, 0 insertions, 0 deletions
