inpcb: Upgrade some lock assertions

[markj]

Summary

INP_HASH_LOCK_ASSERT() asserts that the caller is either in an SMR read
section, or holds the hash lock, which is not in fact a rwlock but is
simply a mutex. However, most users of INP_HASH_LOCK_ASSERT() really
require the mutex, so let's tighten the assertions a bit.

[glebius]

I don't agree with this change. Right now these assertions document that a function does not require write access to the hash. The fact that most callers call them with write lock is a problem, not a feature.

[markj]

In D38363#871914, @glebius wrote:

I don't agree with this change. Right now these assertions document that a function does not require write access to the hash. The fact that most callers call them with write lock is a problem, not a feature.

Are you suggesting that the hash lock should become a true reader/writer lock?

A different approach would be to add something like INP_HASH_SMR_ASSERT() which asserts that the SMR read section is entered or the hash lock is held. Then that assertion would be used in hash lookup routines. Does that sound reasonable?

[glebius]

In D38363#871921, @markj wrote:

Are you suggesting that the hash lock should become a true reader/writer lock?

I didn't suggest that, but it is potentially possible. Why not? If this happens, the current assertions would work. The new assertions that this revision suggests may start failing.

A different approach would be to add something like INP_HASH_SMR_ASSERT() which asserts that the SMR read section is entered or the hash lock is held. Then that assertion would be used in hash lookup routines. Does that sound reasonable?

So you are suggesting to rename INP_HASH_LOCK_ASSERT() into something else that would have a better name. No objection from me! This name of course is inherited from pre-SMR times.