On Tue, Jul 07, 2026 at 07:33:33AM +0000, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s)
> to consider:
> - [Medium] `dept_update_cxt()` hardcodes the process context ID, failing to
> track bottom-half (BH) work items in softirq context and corrupting the
> context of preempted tasks.
> --
>
> commit b8dda7d95e5377770d28c6712cf8fe7fafa98ade
> Author: Byungchul Park <[email protected]>
>
> dept: distinguish each work from another
>
> This commit updates DEPT to assign a different context ID to each work item.
> Since workqueues provide their own concurrency control, wait operations in a
> work item do not prevent events in other works from executing.
>
> > diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> > index c6ea96d5b7167..4a4075d0697c7 100644
> > --- a/kernel/workqueue.c
> > +++ b/kernel/workqueue.c
> [ ... ]
> > @@ -3204,6 +3205,8 @@ __acquires(&pool->lock)
> >
> > lockdep_copy_map(&lockdep_map, &work->lockdep_map);
> > #endif
> > + dept_update_cxt();
> > +
>
> [Severity: Medium]
> Will this unconditionally modify the process context ID, even when tracking
> bottom-half (BH) work items running in softirq context?
Am I missing something? AFAIK, workqueue's workers run in process
context, not softirq context.
> When a BH workqueue executes multiple work items in a single softirq batch,
> process_one_work() executes them and calls dept_update_cxt(). However,
> dept_update_cxt() is implemented as:
It's becasue its not racing with other contexts.
> kernel/dependency/dept.c:dept_update_cxt() {
> struct dept_task *dt = dept_task();
> dt->cxt_id[DEPT_CXT_PROCESS] += 1UL << DEPT_CXTS_NR;
> }
>
> This hardcodes the increment to DEPT_CXT_PROCESS rather than checking
> cur_cxt() to increment DEPT_CXT_SIRQ. Does this cause DEPT to fail in
> distinguishing sequential BH work items and falsely report dependencies?
Are BH works running in softirq context? I will check it.
> Also, can this corrupt the continuous dependency tracking context of
> whatever task was preempted by the softirq?
Process context's cxt_id is referred only in the process context, and
irq context's cxt_id is referred only in the irq context. So no problem.
Byungchul
> > /* ensure we're on the correct CPU */
> > WARN_ON_ONCE(!(pool->flags & POOL_DISASSOCIATED) &&
> > raw_smp_processor_id() != pool->cpu);
>
> --
> Sashiko AI review ยท
> https://sashiko.dev/#/patchset/[email protected]?part=7
