a_us() to check that
the skb is non-null b/f trying to read the timestamp. Possibly something
like this:
Author: Josh Hunt
Date: Tue Jul 30 19:45:43 2024 -0400
workaround empty rtx queue
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 2aac11e7e1cc..d1e2ecbce536 100644
--- a/incl
** Attachment added: "lspci-vnvn.log"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2077657/+attachment/5808087/+files/lspci-vnvn.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2077657
T
** Attachment added: "uname-a.log"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2077657/+attachment/5808086/+files/uname-a.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2077657
Title:
following may be more
appropriate:
Author: Josh Hunt
Date: Tue Jul 30 19:45:43 2024 -0400
tcp: check skb is non-NULL before using in tcp_rto_delta_us()
There have been multiple occassions where we have crashed in this path
because
packets_out suggested there were packets
Thanks @mruffell. No, we're not running a custom kernel. We've just
disabled the 2 sysctsl I mentioned, tcp_early_retrans and tcp_recovery,
for now to mitigate the issue. I just checked and it looks like my
change applies cleanly to the HEAD of focal. I think we'd like to see it
applied to both 5.4
My mitigation was accepted upstream:
https://lore.kernel.org/netdev/172708862651.3320223.2618494280244639290.git-
patchwork-not...@kernel.org/
@mruffell I believe this should be picked up by the stable maintainers.
Do you know how long it will take once it lands there until it's in an
official Ubu
@mruffell my change has been pulled into the latest stable 5.4 and 5.15
kernel queues:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-
queue.git/tree/queue-5.4/tcp-check-skb-is-non-null-in-
tcp_rto_delta_us.patch
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-
queue.
