Everyone who is working on Giant unwinding should be aware of the new
giant wrapper routines which allow us to control whether Giant is turned
on around a subsystem with sysctls.
There are several sysctls:
kern.giant.all defaults to 0 (off). If set to 1 it forces the Giant
wrappers to be turned on for all subsystems regardless of the state
of other kern.giant. sysctls. If set to 0 then Giant is wrapped around
subsystems based on the value of the other kern.giant. sysctls.
General developers should *NOT* mess with any of these sysctls for
As various subsystems get wrapped, those doing the Giant unwinding work
will be able to use these sysctls to turn off Giant and test their work.
Those doing Giant unwinding work will also be able to request that other
developers test their work by turning off Giant around a subsystem, yet
still be able to maintain reasonably stable -current systems for their
Portions of routines that manipulate multiple subsystems may require
that all related Giant management sysctls be turned off in order to
turn off Giant around the routines in question.
Here is an example use for the new wrappers:
/* ARGSUSED */
struct thread *td;
struct getpid_args *uap;
struct proc *p = td->td_proc;
s = mtx_lock_giant(kern_giant_proc);
td->td_retval = p->p_pid;
#if defined(COMPAT_43) || defined(COMPAT_SUNOS)
td->td_retval = p->p_pptr->p_pid;
In this example mtx_lock_giant() is called with kern_giant_proc
(the kern.giant.proc sysctl value) as an argument. The routine returns
whether Giant was actually locked or not. The return value must be passed
to a matching mtx_unlock_giant() later on. (This allows the sysctl
variables to change state out from under the system without blowing things
I am going to begin instrumenting the proc and file code with these
wrappers. I would be very happy to see Alfred, John, and others working
on the Giant wrappers to also start using the wrappers. I believe that
the move to force people to start using the main tree again was a good
one that I believe that these routines will greatly improve the speed
at which -current developers are able to work. Those people who are
working on subsystems should feel free to add additional Giant wrapper
variables and sysctls to kern/kern_mutex.c.
Note that these are long term mechanisms, it will probably be several
years of diminishing bugs before we work the races out.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message