On 10/7/15 6:09 AM, Daniel Borkmann wrote:
bpf_prog_run_clear_cb() wouldn't work on dev_forward_skb() as skb->pkt_type is then being scrubbed to PACKET_HOST, so on the receive path, AF_PACKET might not always see clean skbs->cb[] as assumed ... I think that the skb->pkt_type part needs to be dropped, no?
right. will respin.
Thinking a bit more about this part, which only accounts for fanout_demux_bpf() and run_filter(), so AF_PACKET only, this logic still needs to be slightly different: You currently can have eBPF on packet fanout as a demux and behind that eBPF on the actual packet socket. So, for some reason, fanout could transfer some state to the socket along the way, which could break when cleared as-is via bpf_prog_run_clear_cb(). So we need to make sure to only clear this once, either in front of fanout, or when not present, in front of the socket filter.
no. that would be anti-feature. user space shouldn't rely on such things. If somebody wants to pass data between two disjoint programs (not called via tail_call), they should be using maps or some future per-cpu scratch area that will guarantee such semantics. cb as part of skb is not suitable for that, since it will limit what kernel can do in-between. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
