Kernel panic during pipelined test #926
Comments
|
Reproducing: 10000 connections, regression.test_stress_pipeline.Pipeline.test_pipelined_requests |
|
Related patch which isn't in 4.9.x and corresponding LKML discussion. The patch diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index a0d768fd..4733379c 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -1417,9 +1417,9 @@ EXPORT_SYMBOL(__pskb_copy_fclone);
int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
gfp_t gfp_mask)
{
- int i;
+ int i, osize = skb_end_offset(skb);
u8 *data;
- int size = nhead + skb_end_offset(skb) + ntail;
+ int size = osize + nhead + ntail;
long off;
BUG_ON(nhead < 0);
@@ -1494,6 +1494,13 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
skb->hdr_len = 0;
skb->nohdr = 0;
atomic_set(&skb_shinfo(skb)->dataref, 1);
+
+if (!skb->sk || skb->destructor == sock_edemux)
+ skb->truesize += size - osize;
+BUG_ON(skb->truesize - (skb_headlen(skb)
+ ? SKB_DATA_ALIGN(sizeof(struct sk_buff))
+ : SKB_TRUESIZE(skb_end_offset(skb))) < skb->len);
+
return 0;
nofrags:removes the problem. Note the The , i.e. the |
|
The problem is fixed in https://github.com/tempesta-tech/linux-4.9.35-tfw/pull/5 , but I still get test errors (while there are no any oopses or crashes): |
|
Some of the tests fixed, some of them aren't, see #956 |
krizhanovsky
added a commit
that referenced
this issue
Mar 15, 2018
openvz-integrator
pushed a commit
to OpenVZ/vzkernel
that referenced
this issue
May 19, 2020
Slava Shwartsman reported a warning in skb_try_coalesce(), when we detect skb->truesize is completely wrong. In his case, issue came from IPv6 reassembly coping with malicious datagrams, that forced various pskb_may_pull() to reallocate a bigger skb->head than the one allocated by NIC driver before entering GRO layer. Current code does not change skb->truesize, leaving this burden to callers if they care enough. Blindly changing skb->truesize in pskb_expand_head() is not easy, as some producers might track skb->truesize, for example in xmit path for back pressure feedback (sk->sk_wmem_alloc) We can detect the cases where it should be safe to change skb->truesize : 1) skb is not attached to a socket. 2) If it is attached to a socket, destructor is sock_edemux() My audit gave only two callers doing their own skb->truesize manipulation. I had to remove skb parameter in sock_edemux macro when CONFIG_INET is not set to avoid a compile error. Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Slava Shwartsman <slavash@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> https://jira.sw.ru/browse/PSBM-102386 tempesta-tech/tempesta#926 (cherry picked from commit 158f323) Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com> Backport notes: ieee80211_data_from_8023() hunk has been dropped, seems the functional has been removed by RedHat, anyway, not used since 2012.
openvz-integrator
pushed a commit
to OpenVZ/vzkernel
that referenced
this issue
Jun 9, 2020
Slava Shwartsman reported a warning in skb_try_coalesce(), when we detect skb->truesize is completely wrong. In his case, issue came from IPv6 reassembly coping with malicious datagrams, that forced various pskb_may_pull() to reallocate a bigger skb->head than the one allocated by NIC driver before entering GRO layer. Current code does not change skb->truesize, leaving this burden to callers if they care enough. Blindly changing skb->truesize in pskb_expand_head() is not easy, as some producers might track skb->truesize, for example in xmit path for back pressure feedback (sk->sk_wmem_alloc) We can detect the cases where it should be safe to change skb->truesize : 1) skb is not attached to a socket. 2) If it is attached to a socket, destructor is sock_edemux() My audit gave only two callers doing their own skb->truesize manipulation. I had to remove skb parameter in sock_edemux macro when CONFIG_INET is not set to avoid a compile error. Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Slava Shwartsman <slavash@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> https://jira.sw.ru/browse/PSBM-102386 tempesta-tech/tempesta#926 (cherry picked from commit 158f323) Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com> Backport notes: ieee80211_data_from_8023() hunk has been dropped, seems the functional has been removed by RedHat, anyway, not used since 2012.
openvz-integrator
pushed a commit
to OpenVZ/vzkernel
that referenced
this issue
Sep 23, 2023
Slava Shwartsman reported a warning in skb_try_coalesce(), when we detect skb->truesize is completely wrong. In his case, issue came from IPv6 reassembly coping with malicious datagrams, that forced various pskb_may_pull() to reallocate a bigger skb->head than the one allocated by NIC driver before entering GRO layer. Current code does not change skb->truesize, leaving this burden to callers if they care enough. Blindly changing skb->truesize in pskb_expand_head() is not easy, as some producers might track skb->truesize, for example in xmit path for back pressure feedback (sk->sk_wmem_alloc) We can detect the cases where it should be safe to change skb->truesize : 1) skb is not attached to a socket. 2) If it is attached to a socket, destructor is sock_edemux() My audit gave only two callers doing their own skb->truesize manipulation. I had to remove skb parameter in sock_edemux macro when CONFIG_INET is not set to avoid a compile error. Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Slava Shwartsman <slavash@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> https://jira.sw.ru/browse/PSBM-102386 tempesta-tech/tempesta#926 (cherry picked from commit 158f323) Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com> Backport notes: ieee80211_data_from_8023() hunk has been dropped, seems the functional has been removed by RedHat, anyway, not used since 2012.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: