On Tue, Oct 25, 2022 at 09:29:09AM -0700, Paul E. McKenney wrote:
> On Tue, Oct 25, 2022 at 01:00:02PM -0300, Jason Gunthorpe wrote:
> > On Tue, Oct 25, 2022 at 08:24:20AM -0700, Yonghong Song wrote:
> > > The current uverbs_api_ioctl_method definition:
> > > struct uverbs_api_ioctl_method {
> > > int(__rcu *handler)(struct uverbs_attr_bundle *attrs);
> > > DECLARE_BITMAP(attr_mandatory, UVERBS_API_ATTR_BKEY_LEN);
> > > ...
> > > };
> > > The struct member 'handler' is marked with __rcu. But unless
> > > the function body pointed by 'handler' is changing (e.g., jited)
> > > during runtime, there is no need with __rcu.
> >
> > Huh? This is a sparse marker, it says that the pointer must always be
> > loaded with rcu_dereference
> >
> > It has nothing to do with JIT, this patch is not correct
>
> OK, I will bite...
>
> This is a pointer to a function. Given that this function's code is
> generated at compile time, what sequence of changes is rcu_dereference()
> protecting against?
Module unload. We set the value to NULL and then synchronize_rcu
before unloading the code it points at.
Jason
