Re: [RFC] Backporting "add second dif to raw, inet{6,}, udp, multicast sockets" to LTS 4.9

[Petr Vorel <pvorel@suse.cz>]

Hi David, Greg, all,

> On Sat, Jun 04, 2022 at 10:55:12AM -0600, David Ahern wrote:
> > On 6/4/22 4:08 AM, Greg Kroah-Hartman wrote:
> > > On Fri, Jun 03, 2022 at 10:08:22PM +0200, Petr Vorel wrote:
> > >> Hi all,

> > >> David (both), would it be possible to backport your commits from merge
> > >> 9bcb5a572fd6 ("Merge branch 'net-l3mdev-Support-for-sockets-bound-to-enslaved-device'")
> > >> from v4.14-rc1 to LTS 4.9?

> > >> These commits added second dif to raw, inet{6,}, udp, multicast sockets.
> > >> The change is not a fix but a feature - significant change, therefore I
> > >> understand if you're aginast backporting it.

> > >> My motivation is to get backported to LTS 4.9 these fixes from v5.17 (which
> > >> has been backported to all newer stable/LTS trees):
> > >> 2afc3b5a31f9 ("ping: fix the sk_bound_dev_if match in ping_lookup")
> > >> 35a79e64de29 ("ping: fix the dif and sdif check in ping_lookup")
> > >> cd33bdcbead8 ("ping: remove pr_err from ping_lookup")

> > >> which fix small issue with IPv6 in ICMP datagram socket ("ping" socket).

> > >> These 3 commits depend on 9bcb5a572fd6, particularly on:
> > >> 3fa6f616a7a4d ("net: ipv4: add second dif to inet socket lookups")
> > >> 4297a0ef08572 ("net: ipv6: add second dif to inet6 socket lookups")

> > > Can't the fixes be backported without the larger api changes needed?

> > > If not, how many commits are you trying to backport here?  And there's
> > > no need for David to do this work if you need/want these fixes merged.


> > I think you will find it is a non-trivial amount of work to backport the
> > listed patches and their dependencies to 4.9. That said, the test cases
> > exist in selftests to give someone confidence that it works properly
> > (you will have to remove tests that are not relevant for the
> > capabilities in 4.9).

> And 4.9.y is only going to be supported for 6 more months.  Why not just
> move to 4.14 or newer?  Peter, what is preventing you from doing that if
> you want this issue resolved on your systems?

Thanks a lot both for your input.

I'm sorry to not having check 4.9 EOL before. 6 months till EOL probably does
not justify non-trivial changes to fix this minor issue.

The motivation for me would be to get fixes for SLES15-SP2 LTSS,
afterwards (it's based on 4.12, thus it'd be some more extra work).

I'll might have second look on that, but It's probably not worth of investing lots of time.

Kind regards,
Petr

> thanks,

> greg k-h