[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <88fbfe56-8847-25a5-9301-a573788ca91a@intel.com>
Date: Mon, 5 Oct 2020 10:47:08 +0200
From: Björn Töpel <bjorn.topel@...el.com>
To: Christoph Hellwig <hch@...radead.org>, davem@...emloft.net,
Magnus Karlsson <magnus.karlsson@...el.com>
Cc: ast@...nel.org, daniel@...earbox.net, netdev@...r.kernel.org,
jonathan.lemon@...il.com, maximmi@...lanox.com,
bpf@...r.kernel.org, jeffrey.t.kirsher@...el.com,
anthony.l.nguyen@...el.com, maciej.fijalkowski@...el.com,
maciejromanfijalkowski@...il.com, cristian.dumitrescu@...el.com
Subject: Re: please revert [PATCH bpf-next v5 03/15] xsk: create and free
buffer pool independently from umem
On 2020-10-05 10:43, Christoph Hellwig wrote:
> On Mon, Oct 05, 2020 at 09:35:35AM +0100, Christoph Hellwig wrote:
>> Hi Dave,
>>
>> please can you rever this? This is the second xsk patch this year
>> that pokes into dma-mapping internals for absolutely not reason.
>>
>> And we discussed this in detail the last time around: drivers have
>> absolutely no business poking into dma-direct.h and dma-noncoherent.h.
>> In fact because people do this crap I have a patch to remove these
>> headers that I'm about to queue up, so if this doesn't get reverted
>> the linux-next build will break soon.
>
> Looks like it doesn't actually use any functionality and just
> pointlessly includes internal headers. So just removing dma-direct.h,
> dma-noncoherent.h and swiotlb.h should do the job as well.
>
> But guys, don't do this.
>
Yeah, this commit just moves the work you helped out with [1], and by
accident/sloppiness the internal dma headers were included in the move.
Sorry about that, and we'll try not to repeat this. Apologies for the
extra work on your side.
I'll spin up a patch to fix this asap.
Thanks,
Björn
[1] https://lore.kernel.org/bpf/20200629130359.2690853-5-hch@lst.de/
Powered by blists - more mailing lists