netdev - Re: [net-next v3 00/20][pull request] Intel Wired LAN Driver Updates 2019-12-09

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: <20191210194444.GH46@ziepe.ca>
Date:   Tue, 10 Dec 2019 15:44:44 -0400
From:   Jason Gunthorpe <jgg@...pe.ca>
To:     Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Cc:     davem@...emloft.net, gregkh@...uxfoundation.org,
        netdev@...r.kernel.org, linux-rdma@...r.kernel.org,
        nhorman@...hat.com, sassmann@...hat.com, parav@...lanox.com
Subject: Re: [net-next v3 00/20][pull request] Intel Wired LAN Driver Updates
 2019-12-09

On Tue, Dec 10, 2019 at 11:23:32AM -0800, Jeff Kirsher wrote:
> > I also do not want a headache with conflicts to a huge rdma driver in
> > net, so you cannot send it to -net.
> 
> Agreed, I do not want to cause you or David Miller any headaches.  It was
> not clear on what additional changes the RDMA team would have once their
> driver got upstream.

It isn't about your changes. We often do tree-wide change the RDMA
APIs toward the driver. For instance Leon's work to add restracks and
to move allocations out of drivers. If any driver is out of the
rdma.git tree then this is all broken for us.

> > Mellanox uses a shared branch approach now, it is working well but
> > requires discipline to execute.
> 
> Wouldn't a shared branch cause issues for either you or David Miller to
> pull from, since it has changes from the RDMA and net-next tree's?

The shared tree approach requires discipline and bunch of special
considerations go into constructing it and organizing patches to make
it work. When done properly there are no issues.

> > You can also send your changes to net, wait a cycle then send the rdma
> > changes. IIRC one of the other drivers is working this way.
> 
> This sounds like the best option currently, since there is still a lot of
> work being done in the ice driver.  Since Greg wanted to see driver
> examples, using the virtual bus, I can send the RDMA driver patches as RFC
> in future submissions.  This way, we can make sure the implementation is
> acceptable and will be ready for submission, once the virtual bus and LAN
> driver changes are accepted.

OK

Jason