in[6]_pcblookup_hash_locked() and callers locking after epoch(9)

[bz]

Summary

When in[6]_pcblookup_hash_locked() is called from in[6]_pcblookup_hash() only
the epoch(9) seems to protect it; that means we might be able to get an
inp out of the list which is marked FREED and we need to skip it.

The current solution only checks for FREED after a decision was made, which
in turn might yield an unexpected result, though that would only happen in
rare cases.

While here solve all the "XXX locking" cases in the in[6]_pcblookup_hash_locked()
functions.

I am still a bit uneasy about now taking an RLOCK on the inp where we have not
done so before despite the locking order is relaxed with epoch(9). In theory
the lock order should not change with this patch, given the previous solution
did also take the inp lock in in[6]_pcblookup_hash() (though only for the
assumed result).

PR: 232193

[mmacy]

Is this in response to an observed bug? This is adding a lot of complexity when we can simply validate the result

[bz]

In D17593#375498, @mmacy wrote:

Is this in response to an observed bug? This is adding a lot of complexity when we can simply validate the result

The complexity mostly comes from the fact that we can (and do) now properly lock in the inp when going over the lists (which we couldn't before due to lock order) and with that are less prone to races. Hence this is not just about validating the inp is not FREED but one patch without the other half would make it worse. I can break them up into two if that makes it easier to review/progress.

[bz]

Neither this nor the kernel version (though that one just less likely) is not deadlock safe. It can still happen.

[mmacy]

In D17593#375500, @bz wrote:

In D17593#375498, @mmacy wrote:

Is this in response to an observed bug? This is adding a lot of complexity when we can simply validate the result

The complexity mostly comes from the fact that we can (and do) now properly lock in the inp when going over the lists (which we couldn't before due to lock order) and with that are less prone to races. Hence this is not just about validating the inp is not FREED but one patch without the other half would make it worse. I can break them up into two if that makes it easier to review/progress.

Yes, please.