Re: [PATCH v19 21/40] dept: make dept able to work with an external wgen

[email protected] Tue, 07 Jul 2026 07:33:37 +0000
Newsgroups gmane.linux.kernel.modules,gmane.comp.video.dri.devel,gmane.linux.kernel,gmane.linux.ide
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unconditional zeroing of `wgen` in `dept_event` creates a race condition that systematically loses dependencies for shared locks, blinding the deadlock detector.
--

commit f7ae795e924d8a4b1154e57adaf0e878e810272c
Author: Byungchul Park <[email protected]>

dept: make dept able to work with an external wgen

This commit introduces an external wait generation structure, struct
dept_ext_wgen, to allow subsystems with memory constraints to use DEPT
without embedding a full struct dept_map. It modifies dept_request_event()
and dept_event() to optionally accept and operate on this external wgen
instead of the one embedded in struct dept_map.

> diff --git a/kernel/dependency/dept.c b/kernel/dependency/dept.c
> index 5ef85977e6314..e425d3ab05e5a 100644
> --- a/kernel/dependency/dept.c
> +++ b/kernel/dependency/dept.c
[ ... ]
> @@ -2816,24 +2826,26 @@ void dept_event(struct dept_map *m, unsigned long e_f,
>  	if (m->nocheck)
>  		return;
>  
> +	wg_p = ewg ? &ewg->wgen : &m->wgen;
> +
>  	if (dt->recursive) {
>  		/*
>  		 * Dept won't work with this even though an event
>  		 * context has been asked. Don't make it confused at
>  		 * handling the event. Disable it until the next.
>  		 */
> -		WRITE_ONCE(m->wgen, 0U);
> +		WRITE_ONCE(*wg_p, 0U);
>  		return;
>  	}
>  
>  	flags = dept_enter();
>  
> -	__dept_event(m, m, e_f, ip, e_fn, false);
> +	__dept_event(m, m, e_f, ip, e_fn, false, READ_ONCE(*wg_p));
>  
>  	/*
>  	 * Keep the map diabled until the next sleep.
>  	 */
> -	WRITE_ONCE(m->wgen, 0U);
> +	WRITE_ONCE(*wg_p, 0U);

[Severity: High]
This is a pre-existing issue, but does unconditionally clearing the wgen here
in dept_event() create a race condition that loses dependencies for shared
locks?

When multiple threads hold a shared lock (e.g., a read-lock like
rw_semaphore), and a writer begins waiting, the writer calls
dept_request_event() which sets the lock's wgen. The first reader to unlock
calls dept_event(), which reads the wgen, processes the wait dependency for
its own context, and then unconditionally clears wgen to 0 here.

All subsequent readers unlocking will read 0 and fail to record the dependency
between the writer's wait and their own read-side critical sections, which
could blind the deadlock detector.

Since this issue affects the newly introduced ewg->wgen as well, could this
be addressed to ensure dependencies aren't lost when multiple threads share
the lock?

-- 
Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=21