On Thu, Jul 14, 2022 at 08:20:41AM +0200, Florian Obser wrote:
| On 2022-07-12 14:35 +02, Florian Obser <flor...@openbsd.org> wrote:
| > When the autoconf flag flaps around we might end up with multiple bpf
| > FDs in flight. Things then get confusing. The kernel tells us we can
| > read from the bpf FD but the data is actually "on the other FD", so
| > read(2) returns 0.
| >
| > Found the hard way by, and patiently debugged with weerd@
| >
| > One way to trigger this is booting a vmm VM where dhcpleased(8)'s
| > init_ifaces() loses a race against netstart(8). init_ifaces() would
| > already see the autoconf flag and request a bpf FD.
| > But then it would receive a RTM_IFINFO message without the autoconf flag
| > set from when the interface came up. Then it will see another RTM_IFINFO
| > message with the autoconf flag set and request yet another bpf FD. If
| > the first bpf FD had not arrived yet we ended up with two in the frontend
| > process.
| >
| > While here make sure a bpf FD has been configured before calling
| > close(2) on it.
| >
| > OK?
| >
|
| Anyone? This is a slightly annoying bug... Difficult to hit though.
I found it on a bunch of (vmm) VMs I have around for testing /
experimenting purposes. The change to /etc/rc to start dhcpleased
much earlier was a key factor in triggering it for me. I tried
bisecting kernels, but all the older ones had the same problem (while
I didn't see this issue when running older snapshots). That's when I
realized the /etc/rc change could be relevant somehow.
daily(8) started reporting
> Services that should be running but aren't:
> dhcpleased
Thanks to Florian for the fix, it works well for me.
Paul
--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/
