diff options
| author | Jesper Dangaard Brouer <brouer@redhat.com> | 2018-08-08 23:00:34 +0200 |
|---|---|---|
| committer | Daniel Borkmann <daniel@iogearbox.net> | 2018-08-09 21:50:44 +0200 |
| commit | ad0ab027fc6da08cbd34070d816ff3b7986c64ae (patch) | |
| tree | 36f75aa1790a438a29950b2ecd0dddf9baf0b107 /samples/bpf | |
| parent | bf9bae0ea6ec7013ef37b19fbbf29b62a35474fb (diff) | |
| download | linux-stable-ad0ab027fc6da08cbd34070d816ff3b7986c64ae.tar.gz linux-stable-ad0ab027fc6da08cbd34070d816ff3b7986c64ae.tar.bz2 linux-stable-ad0ab027fc6da08cbd34070d816ff3b7986c64ae.zip | |
xdp: fix bug in cpumap teardown code path
When removing a cpumap entry, a number of syncronization steps happen.
Eventually the teardown code __cpu_map_entry_free is invoked from/via
call_rcu.
The teardown code __cpu_map_entry_free() flushes remaining xdp_frames,
by invoking bq_flush_to_queue, which calls xdp_return_frame_rx_napi().
The issues is that the teardown code is not running in the RX NAPI
code path. Thus, it is not allowed to invoke the NAPI variant of
xdp_return_frame.
This bug was found and triggered by using the --stress-mode option to
the samples/bpf program xdp_redirect_cpu. It is hard to trigger,
because the ptr_ring have to be full and cpumap bulk queue max
contains 8 packets, and a remote CPU is racing to empty the ptr_ring
queue.
Fixes: 389ab7f01af9 ("xdp: introduce xdp_return_frame_rx_napi")
Tested-by: Jean-Tsung Hsiao <jhsiao@redhat.com>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Diffstat (limited to 'samples/bpf')
0 files changed, 0 insertions, 0 deletions