Project

General

Profile

Bug #6470

mac_unregister() needs to mod_hash_remove() BEFORE holding the perimeter.

Added by Dan McDonald about 4 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
networking
Start date:
2015-11-20
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

Digging through old workspaces, I found this one, that was reported to me by Circonus originally.

Essentially, there's a lock-entry inversion between mac_unregister(), and other parts of the mac/GLDv3 code. The mod_hash_remove() call has its own lock, which other mod_hash users acquire, notably mac_pool_update().

Reproducing this bug is straightforward. Get ifconfig(1M) plumb/unplumb looping, get modunload(1M) looping, and get poold starting and stopping. The three attached scripts all just need to be run in the background concurrently and eventually one of the ifconfig(1M) processes will hang, and a kernel coredump will show mac_unregister(), holding the mac perimeter, trying to acquire the mod_hash lock, while mac_pool_update() tries to hold the mac perimeter while holding mod_hash lock.


Files

ifconfig.sh (76 Bytes) ifconfig.sh Dan McDonald, 2015-11-20 03:07 PM
modunload.sh (42 Bytes) modunload.sh Dan McDonald, 2015-11-20 03:07 PM
poold.sh (48 Bytes) poold.sh Dan McDonald, 2015-11-20 03:07 PM

History

#1

Updated by Electric Monk almost 3 years ago

  • % Done changed from 0 to 100
  • Status changed from New to Closed

git commit 8241ccbb39665a24ebedcca509f82ef3f0b6dd83

commit  8241ccbb39665a24ebedcca509f82ef3f0b6dd83
Author: Dan McDonald <danmcd@omniti.com>
Date:   2017-03-03T21:24:44.000Z

    6470 mac_unregister() needs to mod_hash_remove() BEFORE holding the perimeter.
    Reviewed by: Ryan Zezeski <ryan@zinascii.com>
    Reviewed by: Michael Speer <michael.speer@pluribusnetworks.com>
    Approved by: Richard Lowe <richlowe@richlowe.net>

Also available in: Atom PDF