Bug 216510 - panic while adding an epair to a bridge
Summary: panic while adding an epair to a bridge
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: Kristof Provost
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-26 21:20 UTC by nvass
Modified: 2020-07-31 18:08 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description nvass 2017-01-26 21:20:10 UTC
Hi,

After running the following commands I get a panic:
#!/bin/sh
bridge=`ifconfig bridge create`
epair=`ifconfig epair create | sed 's/.$//'`

ifconfig $bridge 11.255.255.1/28
ifconfig $bridge addm ${epair}a



Panic:
panic: _mtx_lock_sleep: recursed on non-recursive mutex if_bridge @ /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:2117

cpuid = 2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00954da260
vpanic() at vpanic+0x186/frame 0xfffffe00954da2e0
kassert_panic() at kassert_panic+0x126/frame 0xfffffe00954da350
__mtx_lock_sleep() at __mtx_lock_sleep+0x3e2/frame 0xfffffe00954da3d0
__mtx_lock_flags() at __mtx_lock_flags+0x116/frame 0xfffffe00954da430
bridge_transmit() at bridge_transmit+0x61/frame 0xfffffe00954da470
ether_output() at ether_output+0x703/frame 0xfffffe00954da510
arprequest() at arprequest+0x413/frame 0xfffffe00954da620
arp_ifinit() at arp_ifinit+0x56/frame 0xfffffe00954da660
arp_handle_ifllchange() at arp_handle_ifllchange+0x3d/frame 0xfffffe00954da680
bridge_ioctl_add() at bridge_ioctl_add+0x3b4/frame 0xfffffe00954da6d0
bridge_ioctl() at bridge_ioctl+0x29f/frame 0xfffffe00954da770
ifioctl() at ifioctl+0xbc8/frame 0xfffffe00954da7f0
kern_ioctl() at kern_ioctl+0x2b0/frame 0xfffffe00954da850
sys_ioctl() at sys_ioctl+0x13f/frame 0xfffffe00954da930
amd64_syscall() at amd64_syscall+0x2f9/frame 0xfffffe00954daab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe00954daab0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800fd5aaa, rsp = 0x7fffffffe1f8, rbp = 0x7fffffffe2a0 ---
KDB: enter: panic
[ thread pid 766 tid 100571 ]
Stopped at      kdb_enter+0x3b: movq    $0,kdb_why
db>
Comment 1 Kristof Provost freebsd_committer 2017-01-26 21:29:47 UTC
Hmm, I can't immediately reproduce this using your instructions.
Do you have any non-default kernel configuration or sysctl settings?

I'm actually a little surprised I can't reproduce it. The panic looks pretty straightforward, and I should be able to panic my box this way too.
Comment 2 nvass 2017-01-26 22:28:35 UTC
Ah yes, I have set sysctl net.link.bridge.inherit_mac to 1
in my /boot/loader.conf and completely forgotten about it.

With the defaults, everything's normal. Set the sysctl and it will panic.
Comment 3 Kristof Provost freebsd_committer 2017-01-26 22:44:05 UTC
(In reply to nvass from comment #2)
Yes, that makes a lot of sense. I've reproduced the problem. Hopefully I'll have a bit of time to think about a fix in the next couple of days.
Comment 4 Kristof Provost freebsd_committer 2017-02-03 16:58:19 UTC
There's a patch in https://reviews.freebsd.org/D9429
Comment 5 nvass 2017-02-05 14:44:41 UTC
I just tried your patch and it solves the problem.
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:43:01 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Comment 7 commit-hook freebsd_committer 2020-04-26 16:27:43 UTC
A commit references this bug:

Author: kp
Date: Sun Apr 26 16:27:03 UTC 2020
New revision: 360346
URL: https://svnweb.freebsd.org/changeset/base/360346

Log:
  bridge tests: Test for #216510

  We used to have an issue with recursive locking with
  net.link.bridge.inherit_mac. This causes us to send an ARP request while
  we hold the BRIDGE_LOCK, which used to cause us to acquire the
  BRIDGE_LOCK again. We can't re-acquire it, so this caused a panic.

  Now that we no longer need to acquire the BRIDGE_LOCK for
  bridge_transmit() this should no longer panic. Test this.

  PR:	216510
  Reviewed by:	emaste, philip
  MFC after:	2 months
  Sponsored by:	The FreeBSD Foundation
  Differential Revision:	https://reviews.freebsd.org/D24251

Changes:
  head/tests/sys/net/if_bridge_test.sh