Re: em0 panic: mutex em0 not owned

On Nov 26, 2007 2:31 PM, Attilio Rao <attilio_at_freebsd.org> wrote:
> 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

Yup, version 1.188 is the fix for this.

Cheers,

Jack