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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 30 Jan 2020 09:44:59 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Taehee Yoo <ap420073@...il.com>
Cc:     David Miller <davem@...emloft.net>, Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net v2 1/6] netdevsim: fix race conditions in netdevsim
 operations

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.