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

Date:   Tue, 10 Dec 2019 15:11:25 -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 10:41:54AM -0800, Jeff Kirsher wrote:
> On Tue, 2019-12-10 at 14:25 -0400, Jason Gunthorpe wrote:
> > On Tue, Dec 10, 2019 at 10:06:41AM -0800, Jeff Kirsher wrote:
> > > > Please don't send new RDMA drivers in pull requests to net. This
> > > > driver is completely unreviewed at this point.
> > > 
> > > This was done because you requested a for a single pull request in an
> > > earlier submission 9 months ago.  I am fine with breaking up
> > > submission,
> > > even though the RDMA driver would be dependent upon the virtual bus and
> > > LAN
> > > driver changes.
> > 
> > If I said that I ment a single pull request *to RDMA* with Dave's acks
> > on the net side, not a single pull request to net.
> > 
> > Given the growth of the net side changes this may be better to use a
> > shared branch methodology.
> 
> I am open to any suggestions you have on submitting these changes that has
> the least amount of thrash for all the maintainers involved.
> 
> My concerns for submitting the network driver changes to the RDMA tree is
> that it will cause David Miller a headache when taking additional LAN
> driver changes that would be affected by the changes that were taken into
> the RDMA tree.

If you send the PR to rdma then you must refrain from sending changes
to net that would conflict with it.

I also do not want a headache with conflicts to a huge rdma driver in
net, so you cannot send it to -net.

Mellanox uses a shared branch approach now, it is working well but
requires discipline to execute.

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.

Jason