[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YpuV7QnQNf3C2m3j@kroah.com>
Date: Sat, 4 Jun 2022 19:27:09 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: David Ahern <dsahern@...il.com>
Cc: Petr Vorel <pvorel@...e.cz>, netdev@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>,
Sasha Levin <sashal@...nel.org>
Subject: Re: [RFC] Backporting "add second dif to raw, inet{6,}, udp,
multicast sockets" to LTS 4.9
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,
greg k-h
Powered by blists - more mailing lists