Date: Thu, 20 Apr 2006 22:27:46 -0400 From: John Baldwin <jhb@freebsd.org> To: John Birrell <jb@freebsd.org> Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 95729 for review Message-ID: <200604202227.47757.jhb@freebsd.org> In-Reply-To: <200604202154.k3KLs0BB022204@repoman.freebsd.org> References: <200604202154.k3KLs0BB022204@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 20 April 2006 05:54 pm, John Birrell wrote: > http://perforce.freebsd.org/chv.cgi?CH=3D95729 > > Change 95729 by jb@jb_freebsd2 on 2006/04/20 21:53:46 > > Use macros to translate Solaris kmem_zalloc(), kmem_alloc() and > kmem_free() calls into their FreeBSD equivalents. This turns out to > be a neat way to port their code. > > Most memory allocations in this driver occur with one or more > mutex/es locked. Since dtrace is part of a released product, I'm > porting this on the assumption that the locking strategy works. > With witness enabled, I can't have it downgrade a M_WAITOK call > to a M_NOWAIT call just because it thinks it's a not a good idea > to sleep with locks held. For this code, we need to do that and > we can't afford to fail because the thing that we might be trying > to trace is the low memory situation. We might not be too > successful, but we need to try. Anyway... that's why the mutexes > are initialised with M_NOWITNESS. This is because FreeBSD mutexes !=3D Solaris mutexes. You may or may not e= nd up=20 with arbitrary panics and deadlocks if the malloc() actually blocks. You could use an sx(9) instead and just use sx_xlock() and sx_xunlock() which w= ill=20 be safe to hold across a blocking malloc(). =2D-=20 John Baldwin <jhb@FreeBSD.org> =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200604202227.47757.jhb>