FreeBSD_stable_10 - Build #1860 - Fixed

[jenkins-admin at FreeBSD.org]

FreeBSD_stable_10 - Build #1860 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_stable_10/1860/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_stable_10/1860/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_stable_10/1860/console

Change summaries:

291652 by fabient:
MFC r291301:

The r241129 description was wrong that the scenario is possible
 only for read locks on pcbs. The same race can happen with write
 lock semantics as well.

 The race scenario:

 - Two threads (1 and 2) locate pcb with writer semantics (INPLOOKUP_WLOCKPCB)
  and do in_pcbref() on it.
 - 1 and 2 both drop the inp hash lock.
 - Another thread (3) grabs the inp hash lock. Then it runs in_pcbfree(),
  which wlocks the pcb. They must happen faster than 1 or 2 come INP_WLOCK()!
 - 1 and 2 congest in INP_WLOCK().
 - 3 does in_pcbremlists(), drops hash lock, and runs in_pcbrele_wlocked(),
  which doesn't free the pcb due to two references on it.
  Then it unlocks the pcb.
 - 1 (or 2) gets wlock on the pcb, runs in_pcbrele_wlocked(), which doesn't
  report inp as freed, due to 2 (or 1) still helding extra reference on it.
  The thread tries to do smth with a disconnected pcb and crashes.

 Submitted by:	emeric.poupon at stormshield.eu
 Reviewed by:	glebius@
 Sponsored by: Stormshield
 Tested by: Cassiano Peixoto, Stormshield