Hello,

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

Bye,
Hannes

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.

Bye,
Hannes

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.

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

On 13.04.2016 22:23, Alexei Starovoitov 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?

Yes, that a eBPF program can register such a hw breakpoint within the kernel after checking for some conditions. The CPU debug registers aren't very big thus we probably can't use more than 4 registrations at one time.

That will be hard to achieve as you said due to mutexes...

That is true, unfortunately.

but we can probably extend perf_event_open() api to allow such hw breakpoints
and attach bpf progs to it.

That is not actually that useful IMHO. I used this feature with systemtap from time to time if I knew the absolute pointer of the memory location I want to trace beforehand, but there was only one situation where this actually made sense. Dynamically registering those trace points would be a huge improvement.

In case of skb tracing, I actually tried the approach to allocate the skbs beforehand, set up the watchpoints from user space on the interesting fields and in case I finally hit the skb to be traced, copied over the content of the skb and reinjected it into the stack. But as said, those are horrible hacks...

Bye,
Hannes