Messages in this thread | | | Date | Wed, 15 Apr 2020 21:24:55 -0400 | From | Steven Rostedt <> | Subject | Re: On trace_*_rcuidle functions in modules |
| |
On Wed, 15 Apr 2020 18:02:58 -0700 Bjorn Andersson <bjorn.andersson@linaro.org> wrote:
> Forgive me, but how is this problem related to the fact that the code is > dynamically loaded, i.e. encapsulated in a module?
It's not.
> > Per the example earlier in this thread, the thing we're worried about is > a use after free in the following scenario, right? > > cpu_pm_unregister_notifier(my_notifier); > kfree(my_data); > > But a driver implementing this snippet might do this regardless of being > builtin or module and afaict exiting probe() unsuccessfully or unbinding > the device would risk triggering this issue?
I know my email was confusing. I was talking about a bug that does not exist. (There is no bug!)
The reason is that rcu is enabled during the call to the notifiers. The above assumes that the my_data usage in the notifier callback is surrounded by rcu_read_lock() (otherwise it's broken regardless of this code or not). The above unregister will call synchronize_rcu() after it removes the notifier which will guarantee that the rcu_read_lock() critical sections would be completed. Then the kfree(my_data) can free my_data with no possible users.
-- Steve
| |