> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> >> 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.
|