Re: [PATCH v19 07/40] dept: distinguish each work from another

[Byungchul Park <byungchul@sk.com>]

On Tue, Jul 07, 2026 at 07:33:33AM +0000, sashiko-bot@kernel.org 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 <byungchul@sk.com>
> 
> 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/20260706061928.66713-1-byungchul@sk.com?part=7