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? 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: 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? Also, can this corrupt the continuous dependency tracking context of whatever task was preempted by the softirq? > /* 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
