Date: Wed, 9 Apr 2003 02:58:26 -0500 From: Alan Cox <alc@cs.rice.edu> To: John Baldwin <jhb@FreeBSD.org> Cc: jeff@FreeBSD.ORG Subject: Re: malloc.9 locking section Message-ID: <20030409075826.GM1112@cs.rice.edu> In-Reply-To: <XFMail.20030408164714.jhb@FreeBSD.org> References: <20030408200256.GJ1112@cs.rice.edu> <XFMail.20030408164714.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030409075826.GM1112>