From owner-cvs-all Thu May 2 10:35:17 2002 Delivered-To: cvs-all@freebsd.org Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by hub.freebsd.org (Postfix) with ESMTP id 7638F37B419 for ; Thu, 2 May 2002 10:35:00 -0700 (PDT) Received: (qmail 23351 invoked from network); 2 May 2002 17:34:59 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail14.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 2 May 2002 17:34:59 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g42HYwF08359; Thu, 2 May 2002 13:34:58 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 02 May 2002 13:34:00 -0400 (EDT) From: John Baldwin To: John Baldwin Subject: RE: cvs commit: src/sys/kern kern_malloc.c src/sys/vm uma_core.c Cc: Jeff Roberson , cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Jeff Roberson Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 02-May-2002 John Baldwin wrote: > > On 02-May-2002 Jeff Roberson wrote: >> On Thu, 2 May 2002, John Baldwin wrote: >> >>> >>> On 02-May-2002 Jeff Roberson wrote: >>> > jeff 2002/05/02 00:22:19 PDT >>> > >>> > Modified files: >>> > sys/kern kern_malloc.c >>> > sys/vm uma_core.c uma_dbg.c >>> > sys/sys malloc.h >>> > Log: >>> > malloc/free(9) no longer require Giant. Use the malloc_mtx to protect >>> > the >>> > mallochash. Mallochash is going to go away as soon as I introduce the >>> > kfree/kmalloc api and partially overhaul the malloc wrapper. This >>> > can't >>> > happen >>> > until all users of the malloc api that expect memory to be aligned on >>> > the >>> > size >>> > of the allocation are fixed. >>> >>> Can malloc() still block and still possibly obtain Giant internally? If >>> so, >>> malloc() should still not be called with other locks held. >>> >> >> Yes, it can. Is this rule due to lock order reversals? If so there are >> certain situations where its use could be permitted. In Geom, for >> example, giant is always acquired after the geom locks. > > Yes but locks can't be held while blocking. So since malloc can block malloc > should still not be called with locks held, even after Giant is dead and > buried. So I should amend: it should probably be ok to hold locks if M_NOWAIT is used. However, we should avoid holding locks for "long" periods of time. Esp. around non-relevant stuff like malloc (doing a malloc() usually isn't very relevant to the consistency of the data structure, you should almost always be able to make the structure consistent somehow, drop the lock, malloc, then lock and make the change, or just malloc first before getting locks and making changes). So just as M_NOWAIT should be discouraged (and I've seen it used in places where it wasn't needed) holding locks across malloc() should be highly discouraged, IMO. >> Jeff -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message