Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] cur_cxt() incorrectly identifies a hardirq interrupting a softirq as a softirq context, mixing dependencies between unrelated execution contexts. -- commit 504ac1eb7d0a4081c645648037ec455b5ec741d7 Author: Byungchul Park <[email protected]> dept: distinguish each kernel context from another Each unique kernel context, in dept's point of view, should be identified on every entrance to kernel mode e.g. system call or user oriented fault. Otherwise, dept may track meaningless dependencies across different kernel context. > diff --git a/kernel/dependency/dept.c b/kernel/dependency/dept.c > index fd091ae28ae27..1c4de1b55730a 100644 > --- a/kernel/dependency/dept.c > +++ b/kernel/dependency/dept.c [ ... ] > -static int cur_irq(void) > +static int cur_cxt(void) > { > if (lockdep_softirq_context(current)) > - return DEPT_SIRQ; > + return DEPT_CXT_SIRQ; > if (lockdep_hardirq_context()) > - return DEPT_HIRQ; > - return DEPT_IRQS_NR; > + return DEPT_CXT_HIRQ; > + return DEPT_CXT_PROCESS; > } [Severity: High] This is a pre-existing issue, but does cur_cxt() incorrectly prioritize softirq over hardirq context here? If a softirq is executing and is interrupted by a hardirq, both lockdep_softirq_context(current) and lockdep_hardirq_context() evaluate to true. Because the softirq check comes first, cur_cxt() will return DEPT_CXT_SIRQ instead of DEPT_CXT_HIRQ. Could this cause the waits and events triggered inside the interrupting hardirq to be erroneously attributed to the interrupted softirq's context, potentially mixing unrelated dependencies and leading to false positive circular dependency reports? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=6
