[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xdp-newbies
Subject:    Re: Issues with bpf_trace_printk
From:       Zvi Effron <zeffron () riotgames ! com>
Date:       2017-08-31 18:14:32
Message-ID: CAC1LvL2Z2ixvu1B74vPCQOR7Rbe0B7nm00YTCyL4x_NSG3fV9Q () mail ! gmail ! com
[Download RAW message or body]

> I actually doubt that the trace printk issue you've seen has anything
> to do with XDP native/generic side, but verifying it would be good
> nevertheless.
>
> For more recent iproute2, you can enforce either side (internally using
> the XDP_FLAGS_DRV_MODE and XDP_FLAGS_SKB_MODE flags Dave just mentioned):
>
> * Enforce native mode:
>
>   ip link set dev foo xdpdrv obj ./xdp_test_kern.o sec .text
>
> * Enforce generic mode:
>
>   ip link set dev foo xdpgeneric obj ./xdp_test_kern.o sec .text

Building the latest (same commit as I used on my HyperV VM) iproute2
tools on my VMware box resulted in "No ELF library support compiled
in." when trying to load an XDP program. I assume I'm missing some
library. I'll have to look into that later. I modified my custom
loader to use the flags and neither VM supports driver mode, so it
looks like both are using the generic XDP driver.

> Did anything else change in your setup, like kernel config, etc, that
> could play a role here?

Kernel configs are the same between VMs. Looking through the list of
installed packages, the only differences I see are that the HyperV VM
is using EFI and HyperV guest tools, and the VMware VM is using BIOS
and the VMware guest tools.

I haven't had a chance yet to try and build a kernel with the
configuration you provided.

Thanks,
--Zvi

On Wed, Aug 30, 2017 at 3:04 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 08/30/2017 11:50 PM, Zvi Effron wrote:
>>
>> I managed to set up my configuration with a VM on VMware Workstation,
>> and it did not reproduce the bug. I think it was using one of the
>> Intel drivers, though, instead of the generic. Is there a way to force
>> the use of the generic driver?
>
>
> I actually doubt that the trace printk issue you've seen has anything
> to do with XDP native/generic side, but verifying it would be good
> nevertheless.
>
> For more recent iproute2, you can enforce either side (internally using
> the XDP_FLAGS_DRV_MODE and XDP_FLAGS_SKB_MODE flags Dave just mentioned):
>
> * Enforce native mode:
>
>   ip link set dev foo xdpdrv obj ./xdp_test_kern.o sec .text
>
> * Enforce generic mode:
>
>   ip link set dev foo xdpgeneric obj ./xdp_test_kern.o sec .text
>
> Did anything else change in your setup, like kernel config, etc, that
> could play a role here?
>
> Thanks,
> Daniel
>
>
>> On Wed, Aug 30, 2017 at 2:25 PM, Daniel Borkmann <daniel@iogearbox.net>
>> wrote:
>>>
>>> On 08/30/2017 07:53 PM, Zvi Effron wrote:
>>>>
>>>>
>>>> I've uploaded the object file to
>>>>
>>>>
>>>> https://drive.google.com/file/d/0B-lMs4mJOgQBU090ZzNtSkVnMTQ/view?usp=sharing
>>>>
>>>> uname -a output: Linux localhost.localdomain 4.12.8-300.fc26.x86_64 #1
>>>> SMP Thu Aug 17 15:30:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
>>>>
>>>> ip -V output: ip utility, iproute2-ss170501
>>>>
>>>> I tried with latest iproute2 built from source (ip -V output: ip
>>>> utility, iproute2-ss170705) and am still having the same issue. (I
>>>> also first noticed this with a custom loader I wrote, so I think the
>>>> loader can probably be ruled out.)
>>>>
>>>> sysctl -a 2> /dev/null | grep bpf output:
>>>> kernel.unprivileged_bpf_disabled = 0
>>>> net.core.bpf_jit_enable = 0
>>>> net.core.bpf_jit_harden = 0
>>>> net.core.bpf_jit_kallsyms = 0
>>>>
>>>> Thanks for helping look into this! Let me know if you need any more
>>>> info.
>>>
>>>
>>> Here are my results with your object file; seems to work fine
>>> for me there, good but still strange. ;) I took the actual 4.12.8
>>> stable kernel.
>>>
>>> # uname -a
>>> Linux linux-2.home 4.12.8 #1 SMP Wed Aug 30 21:27:51 CEST 2017 x86_64
>>> x86_64
>>> x86_64 GNU/Linux
>>> # ip -V
>>> ip utility, iproute2-ss170705
>>> # sysctl -a | grep bpf
>>> kernel.unprivileged_bpf_disabled = 0
>>> net.core.bpf_jit_enable = 0
>>> net.core.bpf_jit_harden = 0
>>> net.core.bpf_jit_kallsyms = 0
>>> # ip link set dev wlp4s0 xdpgeneric obj ./xdp_test_kern.o sec .text
>>> # tc exec bpf dbg                     # cmd is just finding mount and
>>> dumping trace pipe
>>> Running! Hang up with ^C!
>>>
>>>   irq/131-iwlwifi-710   [003] ....   892.116200: : Data start: 90941a
>>> Data
>>> end: 909456
>>>   irq/131-iwlwifi-710   [003] ....   892.116216: : Constant: 1
>>>   irq/131-iwlwifi-710   [003] ....   893.346855: : Data start: 90801a
>>> Data
>>> end: 908044
>>>   irq/131-iwlwifi-710   [003] ....   893.346871: : Constant: 1
>>>   irq/131-iwlwifi-710   [003] ....   893.346917: : Data start: 90801a
>>> Data
>>> end: 908070
>>>   irq/131-iwlwifi-710   [003] ....   893.346921: : Constant: 1
>>>   irq/131-iwlwifi-710   [003] ....   893.654076: : Data start: 90801a
>>> Data
>>> end: 908044
>>>   irq/131-iwlwifi-710   [003] ....   893.654092: : Constant: 1
>>>   irq/131-iwlwifi-710   [003] ....   901.333823: : Data start: 88dfc1a
>>> Data
>>> end: 88dfcb8
>>>   irq/131-iwlwifi-710   [003] ....   901.333839: : Constant: 1
>>>   irq/131-iwlwifi-710   [003] ....   907.578693: : Data start: 90801a
>>> Data
>>> end: 90804c
>>>   irq/131-iwlwifi-710   [003] ....   907.578722: : Constant: 1
>>>   irq/131-iwlwifi-710   [003] ....   908.192621: : Data start: 90801a
>>> Data
>>> end: 908044
>>>   irq/131-iwlwifi-710   [003] ....   908.192634: : Constant: 1
>>>   irq/131-iwlwifi-710   [003] ....   908.192696: : Data start: 90801a
>>> Data
>>> end: 908070
>>>   irq/131-iwlwifi-710   [003] ....   908.192701: : Constant: 1
>>>   irq/131-iwlwifi-710   [003] ....   908.920655: : Data start: 90801a
>>> Data
>>> end: 908044
>>>   irq/131-iwlwifi-710   [003] ....   908.920661: : Constant: 1
>>> [...]
>>>
>>> I attached the config I used just in case you want to try
>>> building 4.12.8 kernel whether that changes anything. Would
>>> be interesting to see.
[prev in list] [next in list] [prev in thread] [next in thread]