Re: [RFC PATCH 1/3] rcu/tasks: Export call_rcu_tasks_rude()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] rcu: missing rcu_barrier_tasks_rude() causes UAF on module unload
--

commit ba4806c534fb61d71e190abff5c0d237c0eb2648
Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>

rcu/tasks: Export call_rcu_tasks_rude()

This commit exports call_rcu_tasks_rude() so that subsystems executing
handlers under preempt_disable() can safely use an asynchronous variant. It
also provides fallbacks to call_rcu when Tasks Rude RCU is not configured.

> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -198,7 +198,11 @@ void rcu_tasks_torture_stats_print(char *tt, char *tf);
>  
>  # ifdef CONFIG_TASKS_RUDE_RCU
>  void synchronize_rcu_tasks_rude(void);
> +void call_rcu_tasks_rude(struct rcu_head *rhp, rcu_callback_t func);

[Severity: High]
Since the asynchronous callback API is being exposed for external use, does
there also need to be an rcu_barrier_tasks_rude() declared so that modules
can safely tear down and wait for pending callbacks?

>  void rcu_tasks_rude_torture_stats_print(char *tt, char *tf);
> +# else
> +# define call_rcu_tasks_rude call_rcu
> +# define synchronize_rcu_tasks_rude synchronize_rcu

[Severity: High]
If a barrier function is introduced, will this fallback block also need a
corresponding fallback definition like
#define rcu_barrier_tasks_rude rcu_barrier?

>  # endif

[ ... ]

> diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h
> --- a/kernel/rcu/tasks.h
> +++ b/kernel/rcu/tasks.h

[ ... ]

> -static void call_rcu_tasks_rude(struct rcu_head *rhp, rcu_callback_t func)
> +void call_rcu_tasks_rude(struct rcu_head *rhp, rcu_callback_t func)
>  {
>  	call_rcu_tasks_generic(rhp, func, &rcu_tasks_rude);
>  }
> +EXPORT_SYMBOL_GPL(call_rcu_tasks_rude);

[Severity: High]
If a loadable module uses this API with a callback pointing into its own text
section, how does its module_exit function wait for the callback to finish
executing before the module unloads? Without an exported barrier function,
could this lead to a use-after-free or invalid instruction execution when the
pending callback is invoked in freed or unmapped memory?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/179060575297.372125.10581329083761385407.stgit@devnote2?part=1