The packet filter can not be NULL since commit 2b9600b4497b [1].
No functional change intended.
- 2b9600b4497b (Add dead_bpf_if structure, that should be used as fake bpf_if during ifnet detach)
MFC after: 1 week
Differential D45196
mlx4, mlx5: Eliminate redundent check for NULL packet filter zlei on May 14 2024, 5:03 AM. Authored by Tags None Referenced Files
Details The packet filter can not be NULL since commit 2b9600b4497b [1]. No functional change intended.
MFC after: 1 week
Diff Detail
Event TimelineComment Actions The referenced commit (2b9600b4497b) seems to be relevant for the detach flow, but it doesn't guarantee there will an if_bpf pointer when a struct ifnet is created. Comment Actions These two seems to be the only uses of if_getbpf() in the tree, unless I mis-grepped. Is this the cause for the change? Comment Actions Actually this change has been in my local branch for months ;) I found that while reviewing @jhibbits 's work https://reviews.freebsd.org/D42082 . Comment Actions You are right. I checked all in-tree sources, almost all if_attach() is invoked and bpfattach() followed by. The only exception is sys/netinet6/ip6_mroute.c, only if_attach() is called but no bpfattach(). I'm not familiar with mroute so can not conclude whether that is intentional or not. Comment Actions Given that all(?) other ethernet drivers unconditionally ETHER_BPF_MTAP() (so, ether_bpf_mtap_if()) if we're worried about the bpf being NULL it's probably better for the check to be in ether_bpf_mtap_if() anyway, letting the netstack deal with that. Comment Actions
No, the first attempt to avoid NULL check is 16d878cc99ef . While that is not perfect and since 2b9600b4497b the packet filter can not be NULL in the whole lifetime of an interface. The only exception is sys/net80211/ieee80211_radiotap.c, the bpf filter vap->iv_rawbpf is not unconditionally attached, and as a sequence bpf_mtap2() is called conditionally. While ieee80211_radiotap is special as that facility is designed for capturing all 802.11 traffic. I'm not familiar with ieee80211, so I can not speak more about it. The sys/netinet6/ip6_mroute.c do not call bpf_[m]tap() if I read the code correctly. |