Thank you for your contribution! Sashiko AI review found 1 potential issue(s) 
to consider:
- [Low] trace/fgraph: mixed goto-based error handling with scope-based cleanup
--

commit 6422a16035934ad7c858389b51cb5a7d9fecc15f
Author: Ye Liu <[email protected]>
tracing/fgraph: convert process/thread iterator to 
for_each_process_thread_rculock

This commit converts the manual rcu_read_lock() and rcu_read_unlock() pair
around the for_each_process_thread() loop in alloc_retstack_tasklist() to use
the for_each_process_thread_rculock() macro. This scopes the RCU read lock to
the loop body using a scoped guard, and removes the manual unlock label in the
error handling path.

> diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c
> index 40d373d65f9b9..f797ce1192233 100644
> --- a/kernel/trace/fgraph.c
> +++ b/kernel/trace/fgraph.c
> @@ -1057,11 +1057,10 @@ static int alloc_retstack_tasklist(unsigned long 
> **ret_stack_list)
>               }
>       }
>  
> -     rcu_read_lock();
> -     for_each_process_thread(g, t) {
> +     for_each_process_thread_rculock(g, t) {
>               if (start == end) {
>                       ret = -EAGAIN;
> -                     goto unlock;
> +                     goto free;

[Severity: Low]
This doesn't cause a direct runtime bug here, but does this change mix
goto-based cleanup with scope-based cleanup?

The for_each_process_thread_rculock() macro initializes a scope-based RCU
guard via scoped_guard(rcu). By using goto free; to jump out of the
scoped guard to a manual cleanup label, this explicitly violates the
strict kernel cleanup rule in include/linux/cleanup.h meant to prevent
double-free and resource leak bugs. That rule states that goto-based
cleanup and scope-based cleanup must never be mixed in the same function.

While jumping out of scoped_guard() here triggers the RCU unlock safely
before executing the manual free label, should alloc_retstack_tasklist()
be fully converted to use scope-based cleanup for the ret_stack_list
allocations as well, or should it stick to manual RCU locks to avoid
mixing paradigms?

>               }
>  
>               if (t->ret_stack == NULL) {

[ ... ]

> @@ -1074,9 +1073,6 @@ static int alloc_retstack_tasklist(unsigned long 
> **ret_stack_list)
>                       t->ret_stack = ret_stack_list[start++];
>               }
>       }
> -
> -unlock:
> -     rcu_read_unlock();
>  free:
>       for (i = start; i < end; i++)
>               kmem_cache_free(fgraph_stack_cachep, ret_stack_list[i]);

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

Reply via email to