pflog: Correctly check if bpf peers are present

[zlei]

Summary

On creating the pflog(4) interface, pflog_clone_create() does an
unconditional bpfattach(). Use bpf_peers_present() which was introduced
in commit 16d878cc99ef [1] to check the presence of bpf peers.

This will save a little CPU cycles. There should be no functional
change.

1. 16d878cc99ef Fix the following bpf(4) race condition which can result in a panic

MFC after: 1 week

[zlei]

sys/netpfil/pf/if_pflog.c

272

IIUC in_cksum() would modify the mbuf. Is that intended for pflog(4) ?

277

And these two counters... I'm not sure if they should be increased only when bpf peers present.

[kp]

sys/netpfil/pf/if_pflog.c

272

I don't think it's expected to modify the mbuf. in_cksum() maps to in_cksum_skip(), which is implemented in sys/netinet/in_cksum.c and as far as I can see it only reads the mbuf.

Arguably in_cksum_skip() should take a const struct mbuf * rather than a struct mbuf *, but I think it can't because m_apply() could be used to modify the mbuf (so in_cksum_skip() can't declare m to be const and then pass it to m_apply()).

277

I think it could be argued either way. On the one hand, the interface does conceptually see all of these packets, but on the other hand, it does nothing if there are no attached bpf peers.

Given that, I'd just keep things as they are.