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. EinsteinReceived 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