From owner-cvs-all Thu May 2 10:16:14 2002 Delivered-To: cvs-all@freebsd.org Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by hub.freebsd.org (Postfix) with ESMTP id D7A2037B41B; Thu, 2 May 2002 10:16:05 -0700 (PDT) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id g42HG5x87871; Thu, 2 May 2002 13:16:05 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Thu, 2 May 2002 13:16:05 -0400 (EDT) From: Jeff Roberson To: John Baldwin Cc: Jeff Roberson , , Subject: RE: cvs commit: src/sys/kern kern_malloc.c src/sys/vm uma_core.c In-Reply-To: Message-ID: <20020502131332.P9763-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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. Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message