Date: Tue, 27 Apr 2010 15:47:15 -0400 From: John Baldwin <jhb@freebsd.org> To: kmacy@freebsd.org Cc: src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r207140 - in user/kmacy/head_page_lock_2/sys: amd64/amd64 kern sys Message-ID: <201004271547.15634.jhb@freebsd.org> In-Reply-To: <l2n82c4140e1004271229h88bb71e6s45822761295d85de@mail.gmail.com> References: <201004240503.o3O53g0D028732@svn.freebsd.org> <201004271306.49294.jhb@freebsd.org> <l2n82c4140e1004271229h88bb71e6s45822761295d85de@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 27 April 2010 3:29:06 pm K. Macy wrote: > On Tue, Apr 27, 2010 at 10:06 AM, John Baldwin <jhb@freebsd.org> wrote: > > On Saturday 24 April 2010 1:03:42 am Kip Macy wrote: > >> Author: kmacy > >> Date: Sat Apr 24 05:03:42 2010 > >> New Revision: 207140 > >> URL: http://svn.freebsd.org/changeset/base/207140 > >> > >> Log: > >> generalize lock stack operations and move to subr_lock.c > >> > >> Modified: > >> user/kmacy/head_page_lock_2/sys/amd64/amd64/pmap.c > >> user/kmacy/head_page_lock_2/sys/kern/kern_mutex.c > >> user/kmacy/head_page_lock_2/sys/kern/subr_lock.c > >> user/kmacy/head_page_lock_2/sys/sys/lock.h > >> > >> Modified: user/kmacy/head_page_lock_2/sys/kern/kern_mutex.c > >> > > ============================================================================== > >> --- user/kmacy/head_page_lock_2/sys/kern/kern_mutex.c Sat Apr 24 03:11:35 > > 2010 (r207139) > >> +++ user/kmacy/head_page_lock_2/sys/kern/kern_mutex.c Sat Apr 24 05:03:42 > > 2010 (r207140) > >> @@ -160,7 +185,7 @@ unlock_mtx(struct lock_object *lock) > >> struct mtx *m; > >> > >> m = (struct mtx *)lock; > >> - mtx_assert(m, MA_OWNED | MA_NOTRECURSED); > >> + mtx_assert(m, MA_OWNED); > >> mtx_unlock(m); > >> return (0); > >> } > > > > Note that this breaks the assertion used to prevent passing a recursed mutex > > to mtx_sleep() or cv_wait(). > > > > Thanks. MA_NOTRECURSED breaks its use in lock_stack, I'll add another > function for it too. Yes, the fault may be that lc_unlock and lc_lock are not truly generic. They were only really designed to handle unlock/lock pairs in mtx_sleep() and friends. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201004271547.15634.jhb>