From owner-freebsd-alpha Fri Dec 13 7:57: 5 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 959BF37B401; Fri, 13 Dec 2002 07:57:04 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20DF843EC5; Fri, 13 Dec 2002 07:57:04 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from rev208-187-98-122.wolsi.com ([208.187.98.122] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18MsBC-0004CG-00; Fri, 13 Dec 2002 07:56:46 -0800 Message-ID: <3DFA02EE.A24BAA86@mindspring.com> Date: Fri, 13 Dec 2002 07:55:26 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Gallatin Cc: Kris Kennaway , current@FreeBSD.ORG, alpha@FreeBSD.ORG, tjr@FreeBSD.ORG, jeff@FreeBSD.ORG Subject: Re: Another UMA panic under load References: <20021212192506.GB8113@rot13.obsecurity.org> <15864.58817.832829.647171@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a49f6c7146136b7a51ee679a75739908533ca473d225a0f487350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Andrew Gallatin wrote: > Ugh. Since it may call kmem_malloc(), UMA must hold Giant. > > This is the same problem the mbuf system has, and its what's > keeping network device drivers under Giant in 5.0. > > Both subsytems should probably have GIANT_REQUIRED at all entry > points so as to catch locking problems like this earlier. No, they should probably be wired into machdep.c, instead. It was pretty obvious (to me) that UMA could not use the kmem primitives, if it wanted to avoid Giant, even right at the beginning of integration. I just assumed that this was known, and that it would be dealt with later, using one of several approaches. IMO, the easiest approach is mapping all physical RAM into the KVA at the start of life, and then apportioning it out from there. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message