Skip to content
  1. Dec 14, 2013
  3. Dec 13, 2013
  5. Dec 12, 2013
    • David S. Miller's avatar
      Merge branch 'bpf' · 70f56132
      David S. Miller authored 
      

Daniel Borkmann says:

====================
bpf/filter updates

This set adds just two minimal helper tools that complement the
already available bpf_jit_disasm and complete BPF tooling; plus
it adds and an extensive documentation update of filter.txt.

Please see individual descriptions for details.
====================

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      70f56132
    • Daniel Borkmann's avatar
      filter: doc: improve BPF documentation · 7924cd5e
      Daniel Borkmann authored 
      

This patch significantly updates the BPF documentation and describes
its internal architecture, Linux extensions, and handling of the
kernel's BPF and JIT engine, plus documents how development can be
facilitated with the help of bpf_dbg, bpf_asm, bpf_jit_disasm.

Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7924cd5e
    • Daniel Borkmann's avatar
      filter: bpf_asm: add minimal bpf asm tool · 3f356385
      Daniel Borkmann authored 
      

There are a couple of valid use cases for a minimal low-level bpf asm
like tool, for example, using/linking to libpcap is not an option, the
required BPF filters use Linux extensions that are not supported by
libpcap's compiler, a filter might be more complex and not cleanly
implementable with libpcap's compiler, particular filter codes should
be optimized differently than libpcap's internal BPF compiler does,
or for security audits of emitted BPF JIT code for prepared set of BPF
instructions resp. BPF JIT compiler development in general.

Then, in such cases writing such a filter in low-level syntax can be
an good alternative, for example, xt_bpf and cls_bpf users might have
requirements that could result in more complex filter code, or one that
cannot be expressed with libpcap (e.g. different return codes in
cls_bpf for flowids on various BPF code paths).

Moreover, BPF JIT implementors may wish to manually write test cases
in order to verify the resulting JIT image, and thus need low-level
access to BPF code generation as well. Therefore, complete the available
toolchain for BPF with this small bpf_asm helper tool for the tools/net/
directory. These 3 complementary minimal helper tools round up and
facilitate BPF development.

Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3f356385
    • Daniel Borkmann's avatar
      filter: bpf_dbg: add minimal bpf debugger · fd981e3c
      Daniel Borkmann authored 
      

This patch adds a minimal BPF debugger that "emulates" the kernel's
BPF engine (w/o extensions) and allows for single stepping (forwards
and backwards through BPF code) or running with >=1 breakpoints through
selected or all packets from a pcap file with a provided user filter
in order to facilitate verification of a BPF program. When a breakpoint
is being hit, it dumps all register contents, decoded instructions and
in case of branches both decoded branch targets as well as other useful
information.

Having this facility is in particular useful to verify BPF programs
against given test traffic *before* attaching to a live system.

With the general availability of cls_bpf, xt_bpf, socket filters,
team driver and e.g. PTP code, all BPF users, quite often a single
more complex BPF program is being used. Reasons for a more complex
BPF program are primarily to optimize execution time for making a
verdict when multiple simple BPF programs are combined into one in
order to prevent parsing same headers multiple times. In particular,
for cls_bpf that can have various return paths for encoding flowids,
and xt_bpf to come to a fw verdict this can be the case.

Therefore, as this can result in more complex and harder to debug
code, it would be very useful to have this minimal tool for testing
purposes. It can also be of help for BPF JIT developers as filters
are "test attached" to the kernel on a temporary socket thus
triggering a JIT image dump when enabled. The tool uses an interactive
libreadline shell with auto-completion and history support.

Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fd981e3c
    • Olof Johansson's avatar
      net: eth: cpsw: 64-bit phys_addr_t and sparse cleanup · 1a3b5056
      Olof Johansson authored 
      

Minor fix for printk format of a phys_addr_t, and the switch of two local
functions to static since they're not used outside of the file.

Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1a3b5056
    • Olof Johansson's avatar
      net: eth: davinci_cpdma: Mark a local variable static · df784160
      Olof Johansson authored 
      

Only used locally. Found by sparse.

Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      df784160
    • Olof Johansson's avatar
      net: eth: davinci_cpdma: 64-bit phys/dma_addr_t cleanup · c767db51
      Olof Johansson authored 
      

Silences the below warnings when building with ARM_LPAE enabled, which
gives longer dma_addr_t by default:

drivers/net/ethernet/ti/davinci_cpdma.c: In function 'cpdma_desc_pool_create':
drivers/net/ethernet/ti/davinci_cpdma.c:182:3: warning: passing argument 3 of 'dma_alloc_attrs' from incompatible pointer type [enabled by default]
drivers/net/ethernet/ti/davinci_cpdma.c: In function 'desc_phys':
drivers/net/ethernet/ti/davinci_cpdma.c:222:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
drivers/net/ethernet/ti/davinci_cpdma.c:223:8: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]

Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c767db51