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: [email protected] Reviewed by: glebius@ Sponsored by: Stormshield Tested by: Cassiano Peixoto, Stormshield _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
