Date: Sun, 15 Dec 2002 11:17:15 +1100 From: Tim Robbins <tjr@FreeBSD.org> To: phk@FreeBSD.org Cc: John Baldwin <jhb@FreeBSD.org>, Peter Wemm <peter@wemm.org>, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_descrip.c Message-ID: <20021215111715.A41695@dilbert.robbins.dropbear.id.au> In-Reply-To: <23879.1039899652@critter.freebsd.dk>; from phk@FreeBSD.org on Sat, Dec 14, 2002 at 10:00:52PM %2B0100 References: <XFMail.20021213173832.jhb@FreeBSD.org> <23879.1039899652@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 14, 2002 at 10:00:52PM +0100, phk@FreeBSD.org wrote:
> In message <XFMail.20021213173832.jhb@FreeBSD.org>, John Baldwin writes:
> >
> >On 13-Dec-2002 Peter Wemm wrote:
> >> "Tim J. Robbins" wrote:
> >>> tjr 2002/12/13 01:59:40 PST
> >>>
> >>> Modified files:
> >>> sys/kern kern_descrip.c
> >>> Log:
> >>> Drop filedesc lock and acquire Giant around calls to malloc() and free().
> >>> These call uma_large_malloc() and uma_large_free() which require Giant.
> >>> Fixes panic when descriptor table is larger than KMEM_ZMAX bytes
> >>> noticed by kkenn.
> >>
> >> What about things like geom which explicitly call malloc without Giant?
> >> Or is it just a problem for large allocations?
> >
> >Just for large allocations which call uma_malloc_large().
>
> Uhm, and just what is the magic size where this happens ?
KMEM_ZMAX. The relevant code is in kern_malloc.c:
96 #define KMEM_ZMAX 65536
174 if (size <= KMEM_ZMAX) {
...
182 va = uma_zalloc(zone, flags);
...
189 } else {
...
192 va = uma_large_malloc(size, flags);
Tim
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021215111715.A41695>