I compiled BPF example from samples/bpf/pare_simple.c (from the Linux kernel tree) with very simple change:
SEC("simple")
int handle_ingress(struct __sk_buff *skb)
{
return TC_ACT_SHOT;
}
So I want ANY packets to be dropped. I install it as follows:
This happens on Ubuntu 16.04.3 LTS with kernel 4.4.0-98, llvm and clang of version 3.8 installed from packages, iproute2 is the latest from github.
$ tc qdisc add dev eth0 clsact
$ tc filter add dev eth0 ingress bpf \
object-file ./net-next.git/samples/bpf/parse_simple.o \
section simple verbose
Prog section 'simple' loaded (5)!
- Type: 3
- Instructions: 2 (0 over limit)
- License: GPL
Verifier analysis:
0: (b7) r0 = 2
1: (95) exit
processed 2 insns, stack depth 0
So it seems it installs successfully, however this filter/ebpf does not drop packets, I generate ingress traffic on eth0 interface, e.g. ICMP, and it passes on. What am I doing wrong?
TL;DR: You should add direct-action flag to the tc filter command, as in
tc filter add dev eth0 ingress bpf \
object-file ./net-next.git/samples/bpf/parse_simple.o \
section simple direct-action verbose
^^^^^^^^^^^^^
The short help for tc bpf filter bpf help mentions this flag, but is has not made its way to the tc-bpf(8) manual page at this time, if I remember correctly.
So, what is this flag for?
eBPF programs can be attached two ways with tc: as actions, or as classifiers. Classifiers, attached with tc filter add, are supposed to be used for filtering packets, and do not apply an action by default. Which means that their return values have the following meaning (from man tc-bpf):
0 , denotes a mismatch
-1 , denotes the default classid configured from the command line
else , everything else will override the default classid to provide a facility for non-linear matching
Actions attached with tc action add, on the other hand, can drop or mirror or perform other operations with packets, but they are not supposed to actually filter them.
Because eBPF is kind of more flexible than the traditional actions and filters of tc, you can actually do both at once, filter a packet (i.e. identify this packet) and perform an action on it. To reflect this flexibility, the direct-action, or da flag was added (for kernel 4.4 or newer, with matching iproute2 package). It tells the kernel to use the return values of actions (TC_ACT_SHOT, TC_ACT_OK, etc.) for classifiers. And this is what you need here to return TC_ACT_SHOT in a way the kernel understands you want to drop the packet.
If I remember correctly, the reason why we use this flag instead of just dropping filters for actions is that you need a filter anyway with tc to attach you action to? (to be confirmed). So with the direct-action flag you do not have to attach both one filter and one action, the filter can do both operations. This should be the preferred way to go for eBPF programming with tc.
Related
I'm trying to offload a small EBPF program to the NIC that uses a map. I can lookup elements in the hash map, but when I add the command bpf_map_update_elem I get back an error when I attempt to load.
14: (85) call bpf_map_update_elem#2
[nfp] map_update: not supported by FW
The driver I'm running:
$ ethtool -i $ETHNAME
driver: nfp
version: 5.15.0-27-generic
firmware-version: 0.0.3.5 0.31 bpf-2.0.6.124 ebpf
expansion-rom-version:
bus-info: 0000:06:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
According to https://www.netronome.com/media/documents/UG_Getting_Started_with_eBPF_Offload.pdf this function should be supported.
Has anybody found a solution?
The document you link states:
Since Kernel 4.17, map updates are supported by our driver. As of this writing, our public firmware does
not contain map update support from the datapath, but this is available on request.
You should contact Netronome's customer support service to get the version of the firmware which supports map updates.
(I worked on this guide and can confirm that, to my knowledge, the firmware with map updates has not been publicly released.)
I'm doing an experiment that write the index of loop into a CPU register R11, then building it with gcc -ffixed-r11 try to let compiler know do not use that reg, and finally using perf to measure it.
But when I check the report (using perf script), the R11 value of most record entry is not what I expected, it supposed to be the number sequence like 1..2..3 or 1..4..7, etc. But actually it just a few fixed value. (possibly affected by system call overwriting?)
How can I let perf records the value I set to the register in my program? Or I must to recompile the whole kernel with -ffixed-r11 to achieve?
Thanks everyone.
You should not try to recompile kernel when you just want to sample some register with perf. As I understand, kernel has its own set of registers and will not overwrite user R11. syscall interface uses some fixed registers which can't be changed (can you try different reg?) and there are often glibc gateways to syscall which may use some additional registers (they are not in kernel, they are user-space code; often generated or written in assembler). You may try using gdb to monitor the register to change to find who did it. It can do this (hmm, one more link to the same user on SO): gdb: breakpoint when register will have value 0xffaa like gdb ./program then gdb commands start; watch $r11; continue; where.
Two weeks age there was question perf-report show value of CPU register about register value sampling with perf:
I follow this document and using perf record with --intr-regs=ax,bx,r15, trying to log additional CPU register information with PEBS record.
While there was x86 & PEBS, ARM may have --intr-regs implemented too. Check output of perf record --intr-regs=\? (man perf-record: "To list the available registers use --intr-regs=\?") to find support status and register names.
To print registers, use perf script -F ip,sym,iregs command. There was example in some linux commits:
# perf record --intr-regs=AX,SP usleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.016 MB perf.data (8 samples) ]
# perf script -F ip,sym,iregs | tail -5
ffffffff8105f42a native_write_msr_safe AX:0xf SP:0xffff8802629c3c00
ffffffff8105f42a native_write_msr_safe AX:0xf SP:0xffff8802629c3c00
ffffffff81761ac0 _raw_spin_lock AX:0xffff8801bfcf8020 SP:0xffff8802629c3ce8
ffffffff81202bf8 __vma_adjust_trans_huge AX:0x7ffc75200000 SP:0xffff8802629c3b30
ffffffff8122b089 dput AX:0x101 SP:0xffff8802629c3c78
#
If you need cycle accurate profile of to the metal CPU activity then perf is not the right tool, as it is at best an approximation due to the fact it only samples the program at select points. See this video on perf by Clang developer Chandler Carruth.
Instead, you should single step through the program in order to monitor exactly what is happening to the registers. Or you could program your system bare metal without an OS, but that is probably outside the scope here.
Using Qsys (Quartus II x64 15.0.1 build 150) I made a system with Nios2/e and several standard peripheral components. I also add my custom component with 1 MM-Slave and 2 Interrupt Senders. For each of them I set this slave as "Associated addressable interface" in Component editor during creation of _hw.tcl file.
Qsys reports no errors or warnings, but then I tried to make BSP project in Eclipse using New | Nios 2 BSP project wizard. I select "SOPC Information File name", but "CPU" ComboBox remains empty and error appears: "No Nios II CPU Found".
Then I launch BSP Editor from main menu: Nios 2 | BSP Editor and press File | New Nios 2 BSP. I again provide SOPC file and this tool found CPU, but also reports the error: "Can only have at most one IRQ associated with the following slaves of module "my_component" : mm_slave."
I then returned to Qsys and remove one of Interrupt Senders and this time everything works fine, but I need to generate more than one interrupt.
So what to do if you have Nios2/e connected to custom peripheral with 1 MM-Slave and several Interrupt Senders?
I have some ideas but don't like them:
Add MM-Slave for each irq (it looks like waste of resources).
Do not specify "Associated addressable interface" in Component editor (it is by the way works, but I don't know will it work properly all the time). What this option really do?
I was imprecise saying that it will work, sorry for that. In reality qsys and BSP can be generated but inside BSP's system.h IRQ number will be defined as -1, so it will not work.
Merge all interrupts into one wire (they all will share the same priority).
Configure Interrupt Sender to have irq signal with width more than 1 (Component Editors allows to do this but reports warning: "interrupt_sender: Signal irq_many[4] of type irq must have width [1]".) As with case 2 I don't know what will happen inside Altera's generators/compilers.
After Component Editor stage is finished Qsys doesn't accept such a system.
Please help.
At last, I have found the following:
A. If you need many IRQ Senders inside one custom Qsys module you need one MM-Slave per each. From GUI organization it seems that you are assigning MM-Slave to the IRQ, but (as far as I understand it) it works directly opposite: IRQ is tied to MM-Slave and it may has maximum one IRQ. I didn't try to actually run it, but BSP files looks correct and everything compiles at least.
I hope, that there is (or will be) a better way to achieve this.
B. If you can share the same priority between all interrupts, than you can avoid the problem by using only 1 Interrupt Sender and thus only 1 MM-Slave. It works on dev board.
I would like to disable c-states on my computer.
I disabled c-state on BIOS but I don't obtain any result. However, I found an explanation :
"Most newer Linux distributions, on systems with Intel processors, use the “intel_idle” driver (probably compiled into your kernel and not a separate module) to use C-states. This driver uses knowledge of the various CPUs to control C-states without input from system firmware (BIOS). This driver will mostly ignore any other BIOS setting and kernel parameters"
I found two solutions to solve this problem but I don't know how to apply:
1) " so if you want control over C-states, you should use kernel parameter “intel_idle.max_cstate=0” to disable this driver."
I don't know neither how I can check the value (of intel_idle.max_cstate ) and neither how I can change its value.
2) "To dynamically control C-states, open the file /dev/cpu_dma_latency and write the maximum allowable latency to it. This will prevent C-states with transition latencies higher than the specified value from being used, as long as the file /dev/cpu_dma_latency is kept open. Writing a maximum allowable latency of 0 will keep the processors in C0"
I can't read the file cpu_dma_latency.
Thanks for your help.
Computer:
Intel Xeon CPU E5-2620
Gnome 2.28.2
Linux 2.6.32-358
To alter the value at boot time, you can modify the GRUB configuration or edit it on the fly -- the method to modify that varies by distribution. This is the Ubuntu documentation to change kernel parameters either for a single boot, or permanently. For a RHEL-derived distribution, I don't see docs that are quite as clear, but you directly modify /boot/grub/grub.conf to include the parameter on the "kernel" lines for each bootable stanza.
For the second part of the question, many device files are read-only or write-only. You could use a small perl script like this (untested and not very clean, but should work) to keep the file open:
#!/usr/bin/perl
use FileHandle;
my $fd = open (">/dev/cpu_dma_latency");
print $fd "0";
print "Press CTRL-C to end.\n";
while (1) {
sleep 5;
}
Redhat has a C snippet in a KB article here as well and more description of the parameter.
I am having troubles with gpio interrupt issue.
According documentation for ep93xx ports A, B, F can be configured to generate interrupts.
quote:
Any of the 19 GPIO lines maybe configured to generate interrupts
However arch/arm/march-ep93xx/gpio.c is handling only interrupts from port A. And doesn't react to port B and F.
static void ep93xx_gpio_ab_irq_handler(unsigned int irq, struct irq_desc *desc)
{
unsigned char status;
int i;
printk(KERN_INFO "ep93xx_gpio_ab_irq_handler: irq=%u", irq);
I know printk is terrible in irq_handlers.
I am configuring iterrupts via sysfs.
GPIO 0,8 are wired with Port F if it is important to issue.
Also when enabling interrupts on port B without having configured port A i get following warning:
------------[ cut here ]------------
WARNING: at drivers/gpio/gpiolib.c:103 gpio_ensure_requested+0x54/0x118()
autorequest GPIO-1
Modules linked in:
[<c002696c>] (unwind_backtrace+0x0/0xf0) from [<c00399d4>] (warn_slowpath_fmt+0x54/0x78)
[<c00399d4>] (warn_slowpath_fmt+0x54/0x78) from [<c019dd90>] (gpio_ensure_requested+0x54/0x118)
[<c019dd90>] (gpio_ensure_requested+0x54/0x118) from [<c019e05c>] (gpio_direction_input+0xb0/0x150)
[<c019e05c>] (gpio_direction_input+0xb0/0x150) from [<c002c9a8>] (ep93xx_gpio_irq_type+0x3c/0x1d8)
[<c002c9a8>] (ep93xx_gpio_irq_type+0x3c/0x1d8) from [<c0066ad8>] (__irq_set_trigger+0x38/0x9c)
[<c0066ad8>] (__irq_set_trigger+0x38/0x9c) from [<c0066e14>] (__setup_irq+0x2d8/0x354)
[<c0066e14>] (__setup_irq+0x2d8/0x354) from [<c0066f38>] (request_threaded_irq+0xa8/0x140)
[<c0066f38>] (request_threaded_irq+0xa8/0x140) from [<c019e784>] (gpio_setup_irq+0x14c/0x260)
[<c019e784>] (gpio_setup_irq+0x14c/0x260) from [<c019ec1c>] (gpio_edge_store+0x90/0xac)
[<c019ec1c>] (gpio_edge_store+0x90/0xac) from [<c01be8fc>] (dev_attr_store+0x1c/0x28)
[<c01be8fc>] (dev_attr_store+0x1c/0x28) from [<c00e8b2c>] (sysfs_write_file+0x168/0x19c)
[<c00e8b2c>] (sysfs_write_file+0x168/0x19c) from [<c009a3d4>] (vfs_write+0xa4/0x160)
[<c009a3d4>] (vfs_write+0xa4/0x160) from [<c009a6a4>] (sys_write+0x3c/0x7c)
[<c009a6a4>] (sys_write+0x3c/0x7c) from [<c0020e40>] (ret_fast_syscall+0x0/0x2c)
---[ end trace ff56c09a294dbe68 ]---
I am using kernel version 2.6.34.14 with linux-2.6.34-ts7200_matt-6.tar.gz patch (hovewer it doesn't seem contain patches for gpio.c or gpiolib.c)
cross version:
binutils-2.23.1
gcc-4.7.3
glibc-2.17
Also i crawled through change history of gpio.c and gpiolib.c and didn't find anything that can be related to this issue.
Can someone give me and advice regarding this issue? I want interrupts on all ports (A,B,F) not just A.
There are a lot of question on this issue (and ARM irq OR interrupt). Please look at them.
We can see many changes by looking at more recent Linux 3.0 gpio.c change logs versus the 2.6.34 logs and the current version. You should be able to get the current Linux stable tree and extract these patches and back port them to your kernel. For instance, there is a bug where port C and F are swapped; I don't know if this is in your ts7200_matt variant.
Some important change sets to look at,
arm: Fold irq_set_chip/irq_set_handler
arm: Cleanup the irq namespace
arm: ep93xx: Use proper irq accessor functions
arm: ep93xx: Add basic interrupt info
ARM: ep93xx: irq_data conversion.
ARM: 5954/1: ep93xx: move gpio interrupt support to gpio.c
[ARM] 5243/1: ep93xx: bugfix, GPIO ports C and F are swapped
You may have #6, but it is worth looking at as it is basically the interrupt implementation for your controller. After about linux-3.0, your SOC's GPIO controller was moved to drivers/gpio/gpio-ep93xx.c. You may wish to look at these changes, but none seem to be related to your issue. You should be aware of structural changes to Linux. Ie, overall changes to interrupt handling and/or the generic GPIO infrastructure. A good guess is that Thomas Gleixner or Russell King will make these changes.
The patches can be extracted from a particular Linux stable tree with git format-patch b685004.. b0ec5cf1 gpio.c. This will create several patch files. Move them to your tree and apply with either git am or patch -p1. You may have to massage these files to get them to apply cleanly to your tree; if you take them all, even though they are not related to interrupt handling, you will have better luck doing this automatically. You can also look at the patch set and try to manually patch the file with a text editor.
None of this addresses your specific questions. However, it gives a path to merge changes from the latest Linux versions. Also, the previous stack overflow questions give details on the structure of the GPIO interrupt handling. Coupled with your data sheet, the Linux GPIO document, and the given change sets, you should be able to fix your own problem. Otherwise, you need someone familiar with the EP93xx and the question is fairly localized.
Note: The stack trace indicates that a GPIO is being used without a corresponding gpio_request()
. This is either a bug in the machine file or in the EP93xx GPIO interrupt handling code.
I had the same warning:
------------[ cut here ]------------
WARNING: at drivers/gpio/gpiolib.c:103 gpio_ensure_requested
From my research we have to call gpio_request_one / gpio_request, before gpio_direction_input.
It fixed the problem for me.
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=99789
http://e2e.ti.com/support/embedded/linux/f/354/p/119946/427889.aspx