On 12 July 2016 at 10:45, Martin Pieuchot <m...@openbsd.org> wrote: > dlg@ could reproduce a panic by running dhclient in a loop on one of his > machines. > > Turns out that there's a race between arplookup() and arpcache() inside > in_arpinput(). If another CPU removes the ARP entry from the table, via > RTM_DELETE, it will free the ARP storage. That means we cannot update > an ARP cache without holding the KERNEL_LOCK(). > > Diff below should prevent the race. A better solution would be to delay > the pool_put() until we call rtfree(9), but this needs more work. >
Sounds reasonable. OK mikeb
