sk_buff填充0 incume_skb tracepoint
这是一个(已删除)上一个问题的后续行动。我发现我要阅读的sk_buff
填充了0
s。请注意,以下代码打印0
两次,一次成功阅读,另一个时间为data_len
的假定值。我在阅读结构上是错误的,还是在进入跟踪点时没有填写?
SEC("tracepoint/skb/consume_skb")
int handle_skb(struct sk_buff *skb)
{
unsigned int data_len = 1;
long ret;
ret = bpf_probe_read_kernel(&data_len, sizeof(data_len), &(skb->data_len));
if (ret < 0) {
bpf_printk("Error on probe read.n \n");
}
bpf_printk("ret: %d \n", ret);
bpf_printk("len: %u \n", data_len);
return 0;
}
(尽管此代码完美地显示了我的问题,但我尝试了许多不同的配置,而没有任何结果更改)
我正在使用的加载程序: gist
任何帮助将不胜感激,谢谢!
编辑
我已经测试了与kfree_skb
相似的东西,这里存在相同的问题。但是,当打印协议
在跟踪点上可用时,我获得了1
,也不能正确。
我现在认为这与设置中的某些内容而不是代码有关。
This is sort of a follow up to a (deleted) previous question. I have discovered that the sk_buff
I am trying to read is filled with 0
s. Note that the following code prints 0
twice, once for the successful read, and another time for the supposed value of data_len
. Am I going wrong about reading the struct, or is it just not filled on entry to the tracepoint?
SEC("tracepoint/skb/consume_skb")
int handle_skb(struct sk_buff *skb)
{
unsigned int data_len = 1;
long ret;
ret = bpf_probe_read_kernel(&data_len, sizeof(data_len), &(skb->data_len));
if (ret < 0) {
bpf_printk("Error on probe read.n \n");
}
bpf_printk("ret: %d \n", ret);
bpf_printk("len: %u \n", data_len);
return 0;
}
(Although this code perfectly shows my problem, I have tried many different configurations without any change to the result)
The loader I am using: gist
Any help would be appreciated, thanks!
EDIT
I have tested something similar with kfree_skb
, here the same problem persists. However when printing protocol
available in the tracepoint I get 1
which also cannot be right.
I am now thinking this has to do with something in the setup instead of the code.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我认为,您正在使用错误的参数格式来
suble_skb
跟踪点。不用使用单个sk_buff
参数,请尝试以下报告:以下代码显示合理的,非零的输出:
ouput:
I think, you are using the wrong argument format for the
consume_skb
tracepoint. Instead of using a singlesk_buff
argument, try the format as reported here:The following code shows reasonable, non-zero output for me:
Ouput:
我不确定为什么,但是我尝试了多种方法来访问
skb
无用的数据。“解决方法”是使用kprobe,因为至少运输标头变得可以阅读:
I am not sure why, but I have tried multiple ways to access the data in
skb
to no avail.A "workaround" is to use a kprobe, as then at least the transport header becomes readable as such: