Re: em0 panic: mutex em0 not owned

From: Attilio Rao <attilio_at_freebsd.org>
Date: Mon, 26 Nov 2007 23:31:27 +0100
2007/11/26, Benjamin Close <Benjamin.Close_at_clearchain.com>:
> Attilio Rao wrote:
> > 2007/11/22, Attilio Rao <attilio_at_freebsd.org>:
> >
> >> 2007/11/22, Benjamin Close <Benjamin.Close_at_clearchain.com>:
> >>
> >>> Hi Folks,
> >>>     With a recent current I'm now getting panics when em0 tries to come up:
> >>>
> >>> panic: mutex em0 not owned at ../../../kern/kern_mutex.c:144
> >>>
> >>> _mtx_assert() + 0xdc
> >>> _callout_stop_safe()+0x5d
> >>> em_stop() + 0x50 (if_em.c:2546)
> >>> em_init_locked()+0x47 (if_em.c:1256)
> >>> em_ioctl()+0x466
> >>> ifhwioctl() + 0x75f
> >>> ifioctl() +0xb0
> >>> kern_ioctl() + 0xa3
> >>>
> >>> This is even after atillos, latest patch.
> >>>
> >> Yes, this is a race access to callout_stop() in em driver.
> >> callout_stop() needs to be called with callout-specific lock held
> >> otherwise you can get a race and this seems not happening. I just
> >> inserted this assertions in order to catch bugs like these.
> >> I have no time to double-check it, can you do?
> >>
> >
> > Ok, basically em_stop() both wants to stop core callout and tx channel
> > callout but it only holds core lock. It needs to hold both in order to
> > stop both. As I'm not sure about lock ordering there I can't produce a
> > patch now so the ball is in jfv_at_ court (CC'ed).
> >
> The attached patch fixes the panic at the cost of a lock order reversal:

jfv_at_ today should have fixed it.
Please cvsup and try again.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
Received on Mon Nov 26 2007 - 21:31:31 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:23 UTC