On 18/08/2020 10:44, Greg KH wrote:
On Tue, Aug 18, 2020 at 10:39:38AM +0200, Matthieu Baerts wrote:
On 18/08/2020 09:20, Greg KH wrote:
On Tue, Aug 18, 2020 at 09:11:36AM +0200, Matthieu Baerts wrote:
On 18/08/2020 09:08, Greg KH wrote:
On Mon, Aug 17, 2020 at 09:28:48PM +0200, Matthieu Baerts wrote:
Hi Greg,
On 17/08/2020 11:59, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
This is a note to let you know that I've just added the patch titled
net: refactor bind_bucket fastreuse into helper
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
net-refactor-bind_bucket-fastreuse-into-helper.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
(...)
Patches currently in stable-queue which might be from tim.froidcoeur@xxxxxxxxxxxx are
queue-4.14/net-refactor-bind_bucket-fastreuse-into-helper.patch
Thank you for backporting this patch!
It seems the backport of the companion patch -- d76f3351cea2 ("net:
initialize fastreuse on inet_inherit_port") -- was lost somewhere for 4.14
version. It was backported in all other newer stable versions: 5.8, 5.7,
5.4, 4.19 but not in 4.14.
The patch backported here is a preparation for the real fix which is the
missing patch.
I guess the intention is to backport d76f3351cea2 to v4.14 as well. If not,
this refactoring is maybe not needed :)
Ugh, that was my fault, thanks for catching this. I've now queued this
up to 4.14.y.
Thank you for having added it!
All these backported patches look good to me!
Thanks for checking.
I stopped at 4.14.y as the code for 4.9.y and 4.4.y changed a bunch in
this area, do you think it's worth doing the backport to those really
old kernels? If not, no big deal, I figured I would ask, as I couldn't
tell how realistic devices running them would hit this issue.
To be honest, my colleague Tim found the issue when looking at something
else on a RHEL 7 (based on a v3.10) kernel :)
We noticed the behaviour with TPROXY was the same on the latest kernel.
The fix for the RHEL 7 kernel was even simpler with the code looking more
like what we have in 4.4.y where we have to move only the if/else block:
https://elixir.bootlin.com/linux/v4.4.232/source/net/ipv4/inet_connection_sock.c#L219
In 4.9.y, tb->fast* variables are set with other code. It is indeed not as
simple to backport:
https://elixir.bootlin.com/linux/v4.9.232/source/net/ipv4/inet_connection_sock.c#L221
I don't know if there are many devices doing a transparent proxy and using a
kernel 4.4.y or 4.9.y. If you think it is needed to backport this fix and if
you need help, we can look at sending patches when we are back from
holidays.
A set of backported patches would be wonderful whenever you get a chance
to get to them, have a nice holiday!
Thank you, we will do that!
Have a good evening!
Matt
--
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net
