Re: [PATCH net v2 1/6] netdevsim: fix race conditions in netdevsim operations

[Jakub Kicinski <kuba@kernel.org>]

On Fri, 31 Jan 2020 00:09:43 +0900, Taehee Yoo wrote:
> > > @@ -99,6 +100,8 @@ new_port_store(struct device *dev, struct device_attribute *attr,
> > >       unsigned int port_index;
> > >       int ret;
> > >
> > > +     if (!nsim_bus_dev->init)
> > > +             return -EBUSY;  
> >
> > I think we should use the acquire/release semantics on those variables.
> > The init should be smp_store_release() and the read in ops should use
> > smp_load_acquire().
> 
> Okay, I will use a barrier for the 'init' variable.
> Should a barrier be used for 'enable' variable too?
> Although this value is protected by nsim_bus_dev_list_lock,
> I didn't use the lock for this value in the nsim_bus_init()
> because I thought it's enough.

To be clear I think the code as you wrote it would behave correctly
(it's reasonable to expect that the call to driver_register() implies
a barrier).

> How do you think about this? Should lock or barrier is needed?

IMO having both of the flag variables have the load/store semantics
(that's both 'init' and 'enable') is just less error prone and easier
to understand.

And then the locks can go back to only protecting the lists, I think.