netdev - RE: [RFC PATCH v5 01/16] RDMA/irdma: Add driver framework definitions

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]

Message-ID: <9DD61F30A802C4429A01CA4200E302A7DCD4FD03@fmsmsx124.amr.corp.intel.com>
Date:   Thu, 23 Apr 2020 23:54:18 +0000
From:   "Saleem, Shiraz" <shiraz.saleem@...el.com>
To:     Jason Gunthorpe <jgg@...pe.ca>
CC:     Leon Romanovsky <leon@...nel.org>,
        "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "Ismail, Mustafa" <mustafa.ismail@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "sassmann@...hat.com" <sassmann@...hat.com>,
        "Patil, Kiran" <kiran.patil@...el.com>,
        "Ertman, David M" <david.m.ertman@...el.com>
Subject: RE: [RFC PATCH v5 01/16] RDMA/irdma: Add driver framework
 definitions

> Subject: Re: [RFC PATCH v5 01/16] RDMA/irdma: Add driver framework
> definitions
> 
> On Thu, Apr 23, 2020 at 05:15:22PM +0000, Saleem, Shiraz wrote:
> > > Subject: Re: [RFC PATCH v5 01/16] RDMA/irdma: Add driver framework
> > > definitions
> > >
> > > On Thu, Apr 23, 2020 at 12:32:48AM +0000, Saleem, Shiraz wrote:
> > >
> > > > we have a split initialization design for gen2 and future products.
> > > > phase1 is control path resource initialization in irdma_probe_dev
> > > > and
> > > > phase-2 is the rest of the resources with the ib registration at
> > > > the end of irdma_open. irdma_close must de-register the ib device
> > > > which will take care of ibdev free too. So it makes sense to keep
> > > > allocation of the ib device in irdma_open.
> > >
> > > The best driver pattern is to allocate the ib_device at the very
> > > start of probe() and use this to anchor all the device resources and memories.
> > >
> > > The whole close/open thing is really weird, you should get rid of it.
> > maybe I missing something. But why is it weird?
> 
> Because the RDMA driver should exist as its own entity. It does not shutdown
> unless the remove() method on is struct device_driver is closed.
> So what exactly are open/cose supposed to be doing? I think it is a left over of
> trying to re-implement the driver model.
> 
> > underlying configuration changes and reset management for the physical
> > function need a light-weight mechanism which is realized with the
> > close/open from netdev PCI drv --> rdma drv.
> 
> > Without a teardown and re-add of virtual device off the bus.
> 
> Yes, that is exactly right. If you have done something so disruptive that the
> ib_device needs to be destroyed then you should unplug/replug the entire virtual
> bus device, that is the correct and sane thing to do.

Well we have resources created in rdma driver probe which are used by any
VF's regardless of the registration of the ib device on the PF.
So doing a virtbus device unregister here for underlying config changes
is more destructive than it needs to be as will trigger the remove()
and blow out those resources too.