em0 panic: mutex em0 not owned
attilio at freebsd.org
Mon Nov 26 14:31:31 PST 2007
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@ court (CC'ed).
> The attached patch fixes the panic at the cost of a lock order reversal:
jfv@ today should have fixed it.
Please cvsup and try again.
Peace can only be achieved by understanding - A. Einstein
More information about the freebsd-current