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] [day] [month] [year] [list]

Message-ID: <CAMArcTXoA8=r0ARzToDhHgyVMco2EP-mE7Wmn2XVjbtZ55sCKg@mail.gmail.com>
Date:   Fri, 31 Jan 2020 15:56:35 +0900
From:   Taehee Yoo <ap420073@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
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 at 02:45, Jakub Kicinski <kuba@...nel.org> wrote:
>

Hi Jakub,

> 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.

I will try to test it then send a v3 patch.
Thank you!
Taehee Yoo