On Wed, Feb 03, 2010 at 04:33:50PM +0100, Ariane van der Steldt wrote:
> On Tue, Feb 02, 2010 at 01:21:55AM +0500, Anton Maksimenkov wrote:
> > 2010/2/2 Anton Maksimenkov <[email protected]>:
> > > Overcomplicated using of RB_TREE in uvm_map_lookup_entry() making it
> > > hard to understand.
> > > I thinking about drop this RB_TREE out from uvm_map.c or completely
> > > rewrite using of this RB_TREE.
> >
> > Oh, sorry, I mean "in uvm_map_findspace()" of course.
>
> I'm pretty sure that function is bugged: I think it doesn't do
> wrap-around on the search for an entry. (Should be easily provable, just
> hint=vm_map_max(map) when entering uvm_map_findspace().)
> You won't notice in kernel space, since every caller will set
> hint=vm_map_min(map), but I suspect a number of failed allocations in
> userspace are actually caused by that.
Yes. Henning has a bgpd core router where bgpd occasionally dies due to
an allocation failure and needs restarting (should be plenty of memory
left, it looks like map starvation). I'm 90% sure that this is the
cause.
It's not so simple to fix though. you can't just go straight to the
start of the map. Say i386 where W^X is done using segments. if you dump
something right at the other end of the segment, that pretty much screws
it. Perhaps going back to the min hint for the protection and trying to
push just a little bit down may work?
-0-
--
In defeat, unbeatable; in victory, unbearable.
-- Winston Churchill, on General Montgomery
