Date: Wed, 09 Apr 2003 12:00:21 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Alan Cox <alc@cs.rice.edu> Cc: smp@FreeBSD.ORG Subject: Re: malloc.9 locking section Message-ID: <XFMail.20030409120021.jhb@FreeBSD.org> In-Reply-To: <20030409075826.GM1112@cs.rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09-Apr-2003 Alan Cox wrote: > On Tue, Apr 08, 2003 at 04:47:14PM -0400, John Baldwin wrote: >> >> On 08-Apr-2003 Alan Cox wrote: >> > On Tue, Apr 08, 2003 at 03:31:40PM -0400, John Baldwin wrote: >> >> >> >> On 17-Mar-2003 Harti Brandt wrote: >> >> > Index: malloc.9 >> >> > =================================================================== >> >> > RCS file: /home/ncvs/src/share/man/man9/malloc.9,v >> >> > retrieving revision 1.30 >> >> > diff -u -r1.30 malloc.9 >> >> > --- malloc.9 24 Feb 2003 05:53:27 -0000 1.30 >> >> > +++ malloc.9 17 Mar 2003 15:06:14 -0000 >> >> > >> >> > [snip] >> >> >> >> Looks good to me. While you are at it, please kill the following >> >> from the manpage (if you aren't already doing so): >> >> >> >> Any calls to malloc() or free() when holding a vnode(9) interlock, will >> >> cause a LOR (Lock Order Reversal) due to the interwining of VM Objects >> >> and Vnodes. >> >> >> > >> > Why? The above statement is true. >> >> It's highly specific. Harti is adding wording to say "don't hold any >> locks when calling malloc() with M_WAITOK," not just vnode interlocks. >> If vnode interlocks are even a problem with M_NOWAIT, then perhaps you >> could add wording for that case to Harti's statement ("even with M_NOWAIT >> one cannot hold vnode interlocks..."). > > Holding a vnode interlock is problematic regardless of whether M_WAITOK > or M_NOWAIT is specified. It's a rather non-obvious special case. Even > free() is problematic. In December or January, I recall there being > several reported lock order reversals due to this. This inspired someone > to add the above comment to the man page. > >> ... My main concern is that I don't want >> a situation where malloc(9) grows a huge laundry list of all the locks >> in the kernel saying that can't be held when it is called. Such a list >> would be hard to maintain and would easily rot, be incomplete, etc. >> > > I think this is a one-of-a-kind special case. The vnode interlock is > the only lock in this part of the memory management system that gets > shared with another part of the kernel. Ok. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20030409120021.jhb>