Re: [PATCH] can: isotp: upgrade 5.15 LTS to latest 6.6 mainline code base

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Oct 30, 2023 at 01:09:41PM +0100, Oliver Hartkopp wrote:
> Hello Greg,
> 
> On 30.10.23 12:38, Greg KH wrote:
> > On Mon, Oct 30, 2023 at 12:31:10PM +0100, Oliver Hartkopp wrote:
> > > The backport of commit 9c5df2f14ee3 ("can: isotp: isotp_ops: fix poll() to
> > > not report false EPOLLOUT events") introduced a new regression where the
> > > fix could potentially introduce new side effects.
> > > 
> > > To reduce the risk of other unmet dependencies and missing fixes and checks
> > > the latest mainline code base is ported back to the 5.15 LTS tree.
> > > 
> > > To meet the former Linux 5.15 API these commits have been reverted:
> > > f4b41f062c42 ("net: remove noblock parameter from skb_recv_datagram()")
> > > 96a7457a14d9 ("can: skb: unify skb CAN frame identification helpers")
> > > dc97391e6610 ("sock: Remove ->sendpage*() in favour of sendmsg(MSG_SPLICE_PAGES)")
> > > 0145462fc802 ("can: isotp: isotp_recvmsg(): use sock_recv_cmsgs() to get SOCK_RXQ_OVFL infos")
> > > 
> > > New features and communication stability measures:
> > > 9f39d36530e5 ("can: isotp: add support for transmission without flow control")
> > > 96d1c81e6a04 ("can: isotp: add module parameter for maximum pdu size")
> > > 4b7fe92c0690 ("can: isotp: add local echo tx processing for consecutive frames")
> > > 530e0d46c613 ("can: isotp: set default value for N_As to 50 micro seconds")
> > 
> > Please send these as individual patches, reverts and then the new ones
> > added, not as one huge commit that we can't review properly at all.
> 
> That would be around 20 patches including fixes and fixes of fixes of fixes.
> For that reason I simply copied the 6.6 code and made the code work in 5.x
> by adapting it to the old 5.x kernel APIs.

20 patches is trivial for us to handle, please do it that way as it
ensures we keep the proper history, AND we know what to backport when in
the future.

When you try to crunch patches together, or do non-upstream changes,
90%+ of the time they end up being wrong or impossible to maintain over
time.

> > But why just 5.15?  What about 6.1.y and 6.5.y?
> 
> I have posted 5.10 and 5.15 for now.
> 6.1 would be only this patch
> 96d1c81e6a04 ("can: isotp: add module parameter for maximum pdu size")
> I can also provide.

Why add new features to older kernels?  That's not going to be ok,
sorry.

And why is can adding module parameters?  This isn't the 1990's, we have
proper ways of doing this correctly (hint, module parameters are not the
way to do that...)

thanks,

greg k-h