On 2018-10-11 12:16 p.m., David Ahern wrote:
IMO, bpf at the fill_info stage is not appropriate.
Somewhere before the skb is formed (and nlmsg is built).
If you go as far as constructing it, then cBPF per what
Sowmini should work; but there will be constructs which
are trickier.
skb->sk (hence attached filter) should be available at that point.
Classical bpf per Sowmini's example maybe trickier.
Better - why dont we have an ebpf hook at this stage and then
we dont have to make changes to the kernel when someone adds
one more field to the filter?
BTW: useful for events as well - not just dumps (as the name
fib_dump_filter suggests)
you mean kernel notifications on internal events?
1. there is no user socket when notifications are created and the
*_fill_info is invoked
2. notifications are global going to potentially many sockets. For these
cases the existing sk_filter is appropriate.
#2 - netlink being a broad/multicast bus with attached listeners.
Yes, you can do it with cBPF but some complexity may occur. Example:
if i was interested to netdevice events of "kind = vxlan &&
admin flag is down" then that is non trivial to do with classical but
would be reasonably comfortable to do with ebpf.
Note:
That filter will work fine for dumps as well since the semantics
are the same.
the win is: in the future when you just wanna add that one new
filter attribute you dont need a kernel patch in and roll in a
new production kernel.
cheers,
jamal
