Re: [PATCH v19 27/40] dept: assign dept map to mmu notifier invalidation synchronization

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unbalanced DEPT tracking context leak in mmu_notifier_invalidate_range_start_nonblock()
--

commit 10f75b8cdecfe9a5cbc6804a1d8ae1770fc9fe67
Author: Byungchul Park <byungchul@xxxxxx>

dept: assign dept map to mmu notifier invalidation synchronization

This commit introduces explicit DEPT tracking contexts to resolve false
positive deadlock reports in mmu_notifier invalidation synchronization.
It annotates the start and end of the event contexts delimited by
mmu_notifier_invalidate_range_start() and _end().

> diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
> --- a/include/linux/mmu_notifier.h
> +++ b/include/linux/mmu_notifier.h
[ ... ]
> @@ -460,6 +474,12 @@ mmu_notifier_invalidate_range_start_nonblock(struct mmu_notifier_range *range)
>  		ret = __mmu_notifier_invalidate_range_start(range);
>  	}
>  	lock_map_release(&__mmu_notifier_invalidate_range_start_map);
> +
> +	/*
> +	 * From now on, waiters could be there by this start until
> +	 * mmu_notifier_invalidate_range_end().
> +	 */
> +	mmu_notifier_invalidate_dept_ecxt_start(range);
>  	return ret;
>  }

[Severity: Medium]
Does this unconditionally start the DEPT event context even if the
non-blocking start fails?

If mmu_notifier_invalidate_range_start_nonblock() returns an error, callers
typically abort and skip calling mmu_notifier_invalidate_range_end(). For
example, in mm/oom_kill.c:__oom_reap_task_mm():

    if (mmu_notifier_invalidate_range_start_nonblock(&range)) {
        tlb_finish_mmu(&tlb);
        ret = false;
        continue;
    }

Could this lead to an unbalanced DEPT context being leaked, as the
corresponding mmu_notifier_invalidate_dept_ecxt_end() will never be called
on the error path?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706061928.66713-1-byungchul@xxxxxx?part=27