Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] Mixing goto-based error cleanup with guard() scopes in the same function (`alloc_retstack_tasklist`). --
commit f2b0046bb431ebefb3d059e22788f2810f0e6684 Author: Ye Liu <[email protected]> kernel: convert process/thread iterators to for_each_*_rcu This commit converts multiple manual rcu_read_lock() and iterator blocks across the kernel to use the new for_each_*_rcu() macros. > diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c > index 40d373d65f9b9..e522433ec8a5a 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_rcu(g, t) { > if (start == end) { > ret = -EAGAIN; > - goto unlock; > + goto free; [Severity: Low] Does this change violate the cleanup subsystem guidelines by mixing paradigms? The for_each_process_thread_rcu() macro expands to include a scoped_guard(rcu). However, alloc_retstack_tasklist() still uses a goto free statement to manually clean up the ret_stack_list array allocations upon error. According to the kernel guidelines in include/linux/cleanup.h, the expectation is that a given function either converts all resources requiring a goto cleanup to scope-based cleanup, or converts none of them. Mixing goto-based error handling with guard() or scoped_guard() scopes in the same function should be avoided. > } > > 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=5
