In r334118, uses of the afdata read lock were converted to epoch
sections. In the old locking protocol for LLEs, the afdata read lock
was used to synchronize lookups with lltable table updates, which were
and are performed with the afdata write lock held. Now, the afdata
write lock doesn't block readers from observing a "doomed" LLE that is
still linked into the lltable. Such a reader may block on the LLE lock
held by the thread that is expiring the LLE, so it effectively holds a
reference on the LLE without having updated its refcount. The thread
preparing to free the LLE will release the LLE write lock after having
scheduled the LLE for a deferred free with epoch_call(); the reader may
then schedule the LLE timer, resulting in a use-after-free when the
callout fires.
Fix the problem by checking for the LLE_LINKED flag after having
acquired the LLE lock during a lookup. If the LLE was unlinked while
the thread performing the lookup was blocked, then upon acquiring the
LLE lock it should just pretend that it never saw the LLE in the first
place. The use of epoch(9) ensures that the LLE won't be freed while
we're blocked on the LLE lock.
Note that LLE_UNLOCKED lookups are unaffected, since the caller cannot
acquire a new reference to the LLE.