Re: protocol timer running before protocol is fully initialized (again) (was re: panic: mtx_lock() of spin mutex ...)

From: Ruslan Ermilov <ru_at_freebsd.org>
Date: Thu, 9 Dec 2004 12:15:24 +0200
Hi Max,

On Thu, Dec 09, 2004 at 04:11:26AM +0100, Max Laier wrote:
> On Thursday 09 December 2004 03:31, Robert Watson wrote:
> > On Wed, 8 Dec 2004, Steve Kargl wrote:
> > > panic: mtx_lock() of spin mutex (null) _at_ sys/netinet/frag6.c:682
> > > cpuid = 0
> > > kdb_backtrace+0x37
> > > panic+0x1d1
> > > _mtx_lock_flags+0x72
> > > frag6_slowtimo+0x26
> > > pfslowtimo+0x5a
> > > softclock+0x1c0
> > > ithread_loop+0x179
> > > fork_exit+0xe9
> > > fork_trampoline+0xe
> > >
> > > This is FreeBSD/amd64 from today's sources of about 30 minutes ago.
> > >
> > >From the instant interpretation unit: it looks like this is another
> >
> > example of a protocl's timeout firing before the protocol is properly
> > initialized, as the mutex appears to be zero'd due to being in BSS.
> 
> Here is a lazy fix:
> http://people.freebsd.org/~mlaier/uipc_domain.c.lazy.diff
> 
> Should help for (almost) sure. This fixes all domains that are initialized in 
> SI_SUB_PROTO_DOMAIN, those that are initialized later on (netgraph e.g.) can 
> still trigger this prime example why it's bad to hook something in before 
> initializing it properly. Unfortunately our code and API force us to do so at 
> the moment :-\
> 
> Please tell me if the patch (apply to src/sys/kern/uipc_domain.c) helps.
> 
I've got the same panic early on boot, but in ip_input(), on i386.
Your patch helps.


Cheers,
-- 
Ruslan Ermilov
ru_at_FreeBSD.org
FreeBSD committer

Received on Thu Dec 09 2004 - 09:15:27 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:24 UTC