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 <[email protected]> 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/[email protected]?part=27
