malloc.9 locking section

[John Baldwin]

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 at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/