> No, as you mentioned, there are plenty of other misconfiguration
> possibilities in and
> outside bpf where something can loop in the stack (or where you can lock
> yourself
> out e.g. drop-all).
I wasn't sure if it should be possible to lock up the kernel with such
a combination of BPF programs. If this is the view generally, then
fair enough I suppose. Maybe this is my ignorance showing, but my
understanding is that with BPF generally we go to great lengths to
make sure things don't block (e.g. making sure a BPF program
terminates eventually) to avoid locking up the kernel. By extension,
should it not also be impossible to block indefinitely in
__netif_receive_skb_core with a combination of two BPF programs that
create a cycle with bpf_redirect_peer? It seems like there are other
provisions in place to avoid misconfiguration or buggy combinations of
programs from breaking things too badly such as the
dev_xmit_recursion() check in __bpf_tx_skb().
> if (dev_xmit_recursion()) {
> net_crit_ratelimited("bpf: recursion limit reached on datapath, buggy bpf program?\n");
> kfree_skb(skb);
> return -ENETDOWN;
> }
-Jordan
