Re: [EXT] Re: [PATCH] cnic: change __GFP_COMP allocation method

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Dec 21, 2023 at 09:33:44AM -0500, John Meneghini wrote:
> Including Greg.
> 
> On 12/21/23 01:48, Christoph Hellwig wrote:
> > On Tue, Dec 19, 2023 at 06:16:38AM +0000, Nilesh Javali wrote:
> > > If you are referring to the series proposed by Chris Leech, then this had
> > > objections. And that was the reason to look for an alternative method for
> > > coherent DMA mapping.
> > > 
> > > [PATCH 0/3] UIO_MEM_DMA_COHERENT for cnic/bnx2/bnx2x
> > 
> > Yes.  Well, Greg (rightly) dislikes what the iscsi drivers have been
> > doing.  But we're stuck supporting them, so I see no way around that.
> 
> If this is true then can we reconsider Chris's patches.
> 
> Red Hat has multiple enterprise customers who are relying on this driver and
> we need to keep it running - at least till the end of RHEL 9.  We can try
> and drop support for bnx2/cnic in RHEL 10 but RHEL 9 is in the middle of its
> life cycle and a failure to address this issue is causing many problems as
> we attempt to keep RHEL 9 current with what's upstream.

So you are trying to tell me to accept kernel patches today to keep
RHEL9 obsolete systems alive?  And then sometime in the future we can
drop those changes because why?  That feels very wrong and confusing.
What does what gets merged in 2024 have to do with RHEL 9 systems?  You
are free to do whatever you want in your enterprise kernels, don't rely
on making me take broken-by-design code and be forced to maintain it for
the next 10+ years please, that's just not nice.

> Greg, can we please take Chris's patches upstream?

It's a total abuse of the UIO api, and I thought I actually had comments
about it doing it incorrectly as well.  Resend them in the new year
after they have been cleaned up and we can reconsider them then, it's
too late now for anything new for 6.8-rc1 with the holidays apon us now
anyway.

And get the "we want you to take this crud and maintain it for forever
because we have to support an obsolete and out-of-date kernel for paying
customers" story a bit more straight so it doesn't sound so bad :)

thanks,

greg k-h