On Sat, 10 Jan 2015 19:39:19 -0800
Philip Guenther <[email protected]> wrote:

> On Mon, 5 Jan 2015, Helg wrote:
> > The man page for LOCK(9) says that if the kernel option LOCKDEBUG is 
> > enabled, additional facilities are provided to assist in determining 
> > deadlock occurrences.
> > 
> > I created a copy of /sys/arch/amd64/conf/GENERIC and added option 
> > LOCKDEBUG. Executing config and then make clean && make results in 
> > warnings like:
> > 
> > implicit declaration of function '__mp_lock'
> > 
> > Adding includes for <sys/mplock.h> in the offending files resolves the 
> > problem but this just doesn't seem right.
> > 
> > Does anyone have any suggestions?
> 
> Yeah, don't use it.  It used to be a lot more when there were still traces 
> of the original "simplelocks" in the tree, but the code to do more with 
> LOCKDEBUG was ripped out as those no-ops were felt to be more misleading 
> than helpful.
> 
> It's dead, Jim, let's bury LOCKDEBUG.
> 
> oks?
> 
> 
> Philip
> 
> Index: sys/arch/i386/i386/trap.c
> ===================================================================
> RCS file: /cvs/src/sys/arch/i386/i386/trap.c,v
> retrieving revision 1.119
> diff -u -p -r1.119 trap.c
> --- sys/arch/i386/i386/trap.c 2 Dec 2014 18:13:10 -0000       1.119
> +++ sys/arch/i386/i386/trap.c 11 Jan 2015 03:33:48 -0000
> @@ -381,11 +381,6 @@ trap(struct trapframe *frame)
>       case T_PAGEFLT:                 /* allow page faults in kernel mode */
>               if (p == 0 || p->p_addr == 0)
>                       goto we_re_toast;
> -#ifdef LOCKDEBUG
> -             /* If we page-fault while in scheduler, we're doomed. */
> -             if (__mp_lock_held(&sched_lock))
> -                     goto we_re_toast;
> -#endif
>  
>               pcb = &p->p_addr->u_pcb;
>  #if 0
> Index: sys/sys/sched.h
> ===================================================================
> RCS file: /cvs/src/sys/sys/sched.h,v
> retrieving revision 1.37
> diff -u -p -r1.37 sched.h
> --- sys/sys/sched.h   17 Oct 2014 01:51:39 -0000      1.37
> +++ sys/sys/sched.h   11 Jan 2015 03:33:48 -0000
> @@ -183,7 +183,7 @@ void remrunqueue(struct proc *);
>               yield();                                                \
>  } while (0)
>  
> -#if defined(MULTIPROCESSOR) || defined(LOCKDEBUG)
> +#if defined(MULTIPROCESSOR)
>  #include <sys/lock.h>
>  
>  /*
> @@ -215,7 +215,7 @@ do {                                                      
>                 \
>       splx(s);                                                        \
>  } while (/* CONSTCOND */ 0)
>  
> -#else /* ! MULTIPROCESSOR || LOCKDEBUG */
> +#else /* ! MULTIPROCESSOR */
>  
>  #define      SCHED_ASSERT_LOCKED()           splassert(IPL_SCHED);
>  #define      SCHED_ASSERT_UNLOCKED()         /* nothing */
> @@ -225,7 +225,7 @@ do {                                                      
>                 \
>  #define      SCHED_LOCK(s)                   s = splsched()
>  #define      SCHED_UNLOCK(s)                 splx(s)
>  
> -#endif /* MULTIPROCESSOR || LOCKDEBUG */
> +#endif /* MULTIPROCESSOR */
>  
>  #endif       /* _KERNEL */
>  #endif       /* _SYS_SCHED_H_ */
> Index: share/man/man9/lock.9
> ===================================================================
> RCS file: /cvs/src/share/man/man9/lock.9,v
> retrieving revision 1.22
> diff -u -p -r1.22 lock.9
> --- share/man/man9/lock.9     9 Jul 2014 14:16:10 -0000       1.22
> +++ share/man/man9/lock.9     11 Jan 2015 03:33:48 -0000
> @@ -57,10 +57,6 @@ single process.
>  It also allows upgrading a shared-access lock to an
>  exclusive-access lock, as well as downgrading an exclusive-access lock
>  to a shared-access lock.
> -.Pp
> -If the kernel option LOCKDEBUG is enabled, additional facilities
> -are provided to record additional lock information.
> -These facilities are provided to assist in determining deadlock occurrences.
>  .Sh FUNCTIONS
>  The functions which operate on locks are:
>  .Bl -tag -width Ds

There's another documentation bug on this man page. The flags parameter
to lockinit can only be 0. If you set it to anything other than this
you end up with a failed KASSERT.

-- 
Helg <[email protected]>

Reply via email to