netdev - Re: [RFC PATCH v2 21/21] netgpu/nvidia: add Nvidia plugin for netgpu

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: <20200728172703.GA5667@infradead.org>
Date:   Tue, 28 Jul 2020 18:27:03 +0100
From:   Christoph Hellwig <hch@...radead.org>
To:     Chris Mason <clm@...com>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Jonathan Lemon <jonathan.lemon@...il.com>,
        netdev@...r.kernel.org, kernel-team@...com
Subject: Re: [RFC PATCH v2 21/21] netgpu/nvidia: add Nvidia plugin for netgpu

On Tue, Jul 28, 2020 at 01:18:48PM -0400, Chris Mason wrote:
> > come after in the future.
> 
> Jonathan, I think we need to do a better job talking about patches that are
> just meant to enable possible users vs patches that we actually hope the
> upstream kernel to take.  Obviously code that only supports out of tree
> drivers isn???t a good fit for the upstream kernel.  From the point of view
> of experimenting with these patches, GPUs benefit a lot from this
> functionality so I think it does make sense to have the enabling patches
> somewhere, just not in this series.

Sorry, but his crap is built only for this use case, and that is what
really pissed people off as it very much looks intentional.

> We???re finding it more common to have pcie switch hops between a [ GPU, NIC
> ] pair and the CPU, which gives a huge advantage to out of tree drivers or
> extensions that can DMA directly between the GPU/NIC without having to copy
> through the CPU.  I???d love to have an alternative built on TCP because
> that???s where we invest the vast majority of our tuning, security and
> interoperability testing.  It???s just more predictable overall.
> 
> This isn???t a new story, but if we can layer on APIs that enable this
> cleanly for in-tree drivers, we can work with the vendors to use better
> supported APIs and have a more stable kernel.  Obviously this is an RFC and
> there???s a long road ahead, but as long as the upstream kernel doesn???t
> provide an answer, out of tree drivers are going to fill in the weak spots.
> 
> Other possible use cases would include also include other GPUs or my
> favorite:
> 
> NVME <-> filesystem <-> NIC with io_uring driving the IO and without copies.

And we have all that working with the existing p2pdma infrastructure (at
least if you're using RDMA insted of badly reinventing it, but it could
be added to other users easily).

That infrastructure is EXPORT_SYMBOL_GPL as it should be for
infrastructure like that, and a lot of his crap just seems to be because
he's working around that.

So I really agree with Gred, this very much looks like a deliberate
trolling attempt.