Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Jun 2006 23:58:56 -0600 (MDT)
From:      Warner Losh <imp@bsdimp.com>
To:        jhb@freebsd.org
Cc:        sam@errno.com, src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org
Subject:   Re: cvs commit: src/sys/kern kern_module.c
Message-ID:  <20060629.235856.74667657.imp@bsdimp.com>
In-Reply-To: <200606270848.29250.jhb@freebsd.org>
References:  <200606261834.k5QIYkEF005337@repoman.freebsd.org> <44A0708C.4090703@errno.com> <200606270848.29250.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
From: John Baldwin <jhb@freebsd.org>
Subject: Re: cvs commit: src/sys/kern kern_module.c
Date: Tue, 27 Jun 2006 08:48:28 -0400

> On Monday 26 June 2006 19:41, Sam Leffler wrote:
> > John Baldwin wrote:
> > > jhb         2006-06-26 18:34:45 UTC
> > > 
> > >   FreeBSD src repository
> > > 
> > >   Modified files:
> > >     sys/kern             kern_module.c 
> > >   Log:
> > >   Address a problem I missed in removing Giant from the kernel linker.  Not
> > >   all of the module event handlers are MP safe yet, so always acquire Giant
> > >   for now when invoking module event handlers.  Eventually we can add an
> > >   MPSAFE flag or some such and add appropriate locking to all module event
> > >   handlers.
> > 
> > I suggest we should be marking things !MPSAFE rather than MPSAFE.
> > 
> > 	Sam
> 
> I would prefer that as well but that would require an exhaustive search of
> all existing module event handlers to determine MPSAFE-ness up front.  With
> the mark as MPSAFE method (such as we've used for syscalls) we can mark things
> MPSAFE (and/or add locking to make them MPSAFE) while doing the exhaustive
> search and eventually when all are MPSAFE we can remove the flag (which I'm
> in the process of doing now with the syscall flag) all the while having a
> functioning system.

We have three cases right now:

	(1) Unknown
	(2) MPSAFE
	(3) NEEDS GIANT

All the unknown ones need giant right now, or at least that's a
reasonable guess.  Certainly all the device driver ones do since you
need giant to do certain device tree activities.

Short of introducing a new API, I'm unsure how we'd be able to
effectively and safely do NEEDS_GIANT marking in the interrum.

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060629.235856.74667657.imp>