Subject: Re: lock bug in getnewvnode, or uvm_km_kmemalloc/uvm_map ?
To: Andrew Brown <atatat@atatdot.net>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 11/21/2002 06:30:57
On Wed, 20 Nov 2002, Andrew Brown wrote:
> > > yes, amap_extend() uses malloc, but at the same time, it will only get
> > > called from a process context when extending an amap. kernel map
> > > entries don't use amaps.
> >
> >Yah, but you don't want it to sleep while the caller is holding locks.
>
> okay, maybe i'm not as well versed in this as some, but...
>
> ...uvm_map() calls amap_extend() to extend an already existing amap.
> that requires that the process is running (ie, not starting up) and
> has caused the amap to be allocated. this sounds like something that
> occurs very much after raid autoconfig time. additionally, since
> we're talking about 1.6, this means the process is extending the amap
> forwards to cover a new allocation (since the backwards extension code
> is new), so the process is already well under way (ie, past
> sys_execve() and past the initial runtime of the dynamic linker). for
> 1.6, that sounds well into multi-user.
Andrew,
I'm confused. How does that relate to not wanting to sleep with raidframe
locks held?
Take care,
Bill