On 04/13/2016 10:23 PM, Alexei Starovoitov via iovisor-dev wrote:

On Wed, Apr 13, 2016 at 12:43 PM, Hannes Frederic Sowa via iovisor-dev
<iovisor-dev@...> wrote:

Hello,

On 13.04.2016 20:53, Hannes Frederic Sowa wrote:

if a bpf counterpart of this example would be possible, it would be
really cool:

http://lxr.free-electrons.com/source/samples/hw_breakpoint/data_breakpoint.c

Care must be taken, as the code path in this example as-is is only valid
from process context, as mutexes will be taken during the installation of
the watch point. This actually renders it a little bit moot from the usage
in the networking stack.

I once had an netfilter code which reinserted the skb from a workqueue, but
it was rather horrible to deal with.

do you propose to let programs register such hw breakpoints to point to
other programs?
That will be hard to achieve as you said due to mutexes...
but we can probably extend perf_event_open() api to allow such hw breakpoints
and attach bpf progs to it.

Actually for network debugging it would be nice if we could classify an skb
e.g. from XDP (when passed to stack) or cls_bpf ingress, and tell the kernel
that if this particular skb changes e.g. its protocol or priority field, set
a breakpoint, so I can debug the issue in relation to it. Means that the setting
of breakpoint would be a root-only helper function and the callback it triggers
would need to be a new BPF program type that has helpers such as 'throw stack
trace' etc, and that can inspect struct members. With the mutex, yeah, it's
an issue, maybe it can be worked around ...