Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 _at_ /usr/src/sys/dev/e1000/if_lem.c:881

Hi,

On Fri, Jul 27, 2012 at 4:31 PM, Adrian Chadd <adrian_at_freebsd.org> wrote:
> It looks like a case of "lock held during call up the stack". This is
> bad for so many reasons.
>
> It also makes writing correctly locked drivers a pain in the ass as
> the moment you unlock the driver before calling ether_input() /
> ieee80211_input(), you allow things to change state. So no, although
> you shouldn't use long-held locks to protect things, apparently this
> is all the rage.
>
> iwn(4) does this. ath(4) does not. I'm having a right painful time
> trying to fine-grain lock things. I'm at the point where I'm about to
> not care, rip out all the locks and replace with a single ATH_LOCK().
>
How would a single ATH_LOCK() helps here ? AFAICS, the panic seem to
be a classical fallout from direct dispatch where you can re-enter the
driver from the driver itself through the network stack.

 - Arnaud

> Adrian
>
> On 27 July 2012 11:47, Dimitry Andric <dim_at_freebsd.org> wrote:
>> On 2012-07-26 17:46, David Wolfskill wrote:
>>> This is at r238795; cut/paste of backtrace:
>>>
>>> KDB: enter: panic
>>> [ thread pid 12 tid 100026 ]
>>> Stopped at      kdb_enter+0x3d: movl    $0,kdb_why
>>> db> bt
>>> Tracing pid 12 tid 100026 td 0xc6755000
>>> kdb_enter(c0f93c5f,c0f93c5f,c0f91e21,f08398f0,c1825c80,...) at kdb_enter+0x3d
>>> panic(c0f91e21,c66739a0,c0f20db8,371,c6755000,...) at panic+0x1c4
>>> _mtx_lock_sleep(c68b8560,c6755000,c0f20db8,c0f20db8,371,...) at _mtx_lock_sleep+0x35e
>>> _mtx_lock_flags(c68b8560,0,c0f20db8,371,0,...) at _mtx_lock_flags+0xdb
>>> lem_start(c68ba000,0,c0fa806c,d20,2a,...) at lem_start+0x33
>>> if_transmit(c68ba000,c93d9000,6,c6755000,c65da588,...) at if_transmit+0x129
>>> ether_output(c68ba000,c93d9000,f0839aa4,0,0,...) at ether_output+0x5df
>>> arpintr(c93d9000,8,c0f50314,153,0,...) at arpintr+0x108c
>>> netisr_dispatch_src(7,0,c93d9000,c93d9000,c68ba000,c93d0806) at netisr_dispatch_src+0xa7
>>> netisr_dispatch(7,c93d9000,c93d9000,10,3,...) at netisr_dispatch+0x20
>>> ether_demux(c68ba000,c93d9000,3,0,3,...) at ether_demux+0x133
>>> ether_nh_input(c93d9000,c8f012c8,644d6000,c9492d00,0,...) at ether_nh_input+0x329
>>> netisr_dispatch_src(9,0,c93d9000,e2e,2,1) at netisr_dispatch_src+0xa7
>>> netisr_dispatch(9,c93d9000) at netisr_dispatch+0x20
>>> ether_input(c68ba000,c93d9000,c0f20db8,e2e,c11454c0,...) at ether_input+0x21
>>> lem_intr(c68b6000,8,c0f8e00d,561,0,...) at lem_intr+0x567
>>> intr_event_execute_handlers(c11454c0,c6626200,c0f8e00d,561,c6755000,...) at intr_event_execute_handlers+0xc5
>>> ithread_loop(c6627730,f0839d08,c0f8dd64,3db,0,...) at ithread_loop+0xe2
>>> fork_exit(c0a2dcb0,c6627730,f0839d08) at fork_exit+0x7c
>>> fork_trampoline() at fork_trampoline+0x8
>>> --- trap 0, eip = 0, esp = 0xf0839d40, ebp = 0 ---
>>> db> show locks
>>> exclusive sleep mutex em0 (EM TX Lock) r = 0 (0xc68b8560) locked _at_ /usr/src/sys/dev/e1000/if_lem.c:1324
>>> exclusive sleep mutex em0 (EM Core Lock) r = 0 (0xc68b854c) locked _at_ /usr/src/sys/dev/e1000/if_lem.c:1302
>>> db>
>>>
>>> I need to head off to a meeting; I can poke at the machine a bit more
>>> in a couple of hours or so.
>>
>> I get the same panic and backtrace here, while running as a VMware
>> guest.  At least, as soon something actually happens with the network.
>> _______________________________________________
>> freebsd-current_at_freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"