netdev - Re: [PATCH 5/7] ibmvnic: use a lock to serialize remove/reset

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: <20210111201534.GB178503@us.ibm.com>
Date:   Mon, 11 Jan 2021 12:15:34 -0800
From:   Sukadev Bhattiprolu <sukadev@...ux.ibm.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, Dany Madden <drt@...ux.ibm.com>,
        Lijun Pan <ljp@...ux.ibm.com>
Subject: Re: [PATCH 5/7] ibmvnic: use a lock to serialize remove/reset

Jakub Kicinski [kuba@...nel.org] wrote:
> On Sun, 10 Jan 2021 19:52:25 -0800 Sukadev Bhattiprolu wrote:
> > Jakub Kicinski [kuba@...nel.org] wrote:
> > > On Thu,  7 Jan 2021 23:12:34 -0800 Sukadev Bhattiprolu wrote:  
> > > > Use a separate lock to serialze ibmvnic_reset() and ibmvnic_remove()
> > > > functions. ibmvnic_reset() schedules work for the worker thread and
> > > > ibmvnic_remove() flushes the work before removing the adapter. We
> > > > don't want any work to be scheduled once we start removing the
> > > > adapter (i.e after we have already flushed the work).  
> > > 
> > > Locking based on functions, not on data being accessed is questionable
> > > IMO. If you don't want work to be scheduled isn't it enough to have a
> > > bit / flag that you set to let other flows know not to schedule reset?  
> > 
> > Maybe I could improve the description, but the "data" being protected
> > is the work queue. Basically don't add to the work queue while/after
> > it is (being) flushed.
> > 
> > Existing code is checking for the VNIC_REMOVING state before scheduling
> > the work but without a lock. If state goes to REMOVING after we check,
> > we could schedule work after the flush?
> 
> I see, and you can't just use the state_lock because it has to be a
> spin_lock? If that's the case please just update the commit message 
> and comments to describe the data protected.

Yes, has to be spin lock. Will update description.

Thanks,

Sukadev