netdev - Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and implement private channel OPs

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: <20210126005928.GF4147@nvidia.com>
Date:   Mon, 25 Jan 2021 20:59:28 -0400
From:   Jason Gunthorpe <jgg@...dia.com>
To:     "Saleem, Shiraz" <shiraz.saleem@...el.com>
CC:     "dledford@...hat.com" <dledford@...hat.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Ertman, David M" <david.m.ertman@...el.com>,
        "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
        "Ismail, Mustafa" <mustafa.ismail@...el.com>
Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
 implement private channel OPs

On Tue, Jan 26, 2021 at 12:42:16AM +0000, Saleem, Shiraz wrote:

> I think this essentially means doing away with .open/.close piece. 

Yes, that too, and probably the FSM as well.

> Or are you saying that is ok?  Yes we had a discussion in the past
> and I thought we concluded. But maybe I misunderstood.
> 
> https://lore.kernel.org/linux-rdma/9DD61F30A802C4429A01CA4200E302A7DCD4FD03@fmsmsx124.amr.corp.intel.com/

Well, having now seen how aux bus ended up and the way it effected the
mlx5 driver, I am more firmly of the opinion this needs to be
fixed. It is extremly hard to get everything right with two different
registration schemes running around.

You never answered my question:

> Still, you need to be able to cope with the user unbinding your
> drivers in any order via sysfs. What happens to the VFs when the PF is
> unbound and releases whatever resources? This is where the broadcom
> driver ran into troubles..

?

> PF due to underlying config changes which require a
> de-reg/re-registration of the ibdevice.  Today such config changes
> are handled with the netdev PCI driver using the .close() private
> callback into rdma driver which unregister ibdevice in PF while
> allowing the RDMA VF to survive.

Putting resources the device needs to function in the aux driver is no
good, managing shared resources is the role of the PCI function owning
core driver.

If you put the open/close on the aux device_driver struct and got rid
of the redundant life cycle stuff, it might be OK enough, assuming
there is a good answer to the question above.

Jason