[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <DB9P251MB0389185A863D0592961A259485849@DB9P251MB0389.EURP251.PROD.OUTLOOK.COM>
Date: Fri, 24 Mar 2023 16:23:59 +0000
From: Farbod Shahinfar <farbod.shahinfar@...imi.it>
To: "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Kernel panic on bpf_skb_pull_data
Hello everyone,
I am performing some test with BPF SK_SKB and I have encountered a
scenario resulting in kernel panic. I use a BPF_SK_SKB_STREAM_PARSER
program to parse a request which might be spanning multiple TCP
segments. If the end of request is detected in the parser program it
returns skb->len, passing the request to the
BPF_SK_SKB_STREAM_VERDICT program, and otherwise it returns 0, waiting
for more data to be received. You can find the BPF program attached
(bpf_test.c). Is there an assumption that the program violates?
To reproduce the crashing scenario, I use the python script attached
(client.py) which sends data in chunks toward the bpf program. Usually,
the kernel crashes on the 3rd segment.
To provide more information, I have attached some crash logs. I have
tested this on kernel version 6.1.0 (slightly modified) and version
6.2.8 (unmodified, obtained from kernel.org). It seems that the panic
happens when invoking the bpf_skb_pull_data.
Is this a known issue or is there any information that I can provide to help resolve it?
Sincerely,
Farbod Shahinfar
PhD student at Politecnico di Milano
https://fshahinfar1.github.io/
View attachment "kernel_crash_log_ver_6.2.8.txt" of type "text/plain" (6600 bytes)
View attachment "kernel_crash_log_ver_6.1.0.txt" of type "text/plain" (5368 bytes)
View attachment "client_py.txt" of type "text/plain" (1108 bytes)
View attachment "bpf_test.c" of type "text/x-csrc" (1460 bytes)
Powered by blists - more mailing lists