Re: [PATCH v19 06/40] dept: distinguish each kernel context from another

[sashiko-bot@kernel.org]

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 <byungchul@sk.com>

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/20260706061928.66713-1-byungchul@sk.com?part=6