Subject: Re: Wine & NetBSD?
To: None <>
From: Chuck Cranor <>
List: tech-kern
Date: 11/21/2001 22:03:30
In article <20011118025909.A26999@krishna>,
Bang Jun-Young <> wrote:
>-	} else {
>-		/*
>-		 * not fixed: make sure we skip over the largest possible heap.
>-		 * we will refine our guess later (e.g. to account for VAC, etc)
>-		 */
>-		addr = MAX(addr, round_page((vaddr_t)p->p_vmspace->vm_daddr +
>-					    MAXDSIZ));
> 	}
>+	/*
>+	 * XXX for non-fixed mappings where no hint is provided or
>+	 * the hint would fall in the potential heap space,
>+	 * place it after the end of the largest possible heap.
>+	 *
>+	 * There should really be a pmap call to determine a reasonable
>+	 * location.
>+	 */
>+	else if (addr == 0 ||
>+	    (addr >= round_page((vaddr_t)p->p_vmspace->vm_taddr) &&
>+	     addr < round_page((vaddr_t)p->p_vmspace->vm_daddr + MAXDSIZ)))
>+		addr = round_page((vaddr_t)p->p_vmspace->vm_daddr + MAXDSIZ);


   as previously discussed, the reason for the MAX stuff in the current
code is so that we don't put mmap'd memory in the area reserved for the 
heap (e.g. malloc() area).   that area is being protected.

   the problem with your patch is this: suppose you set addr to a value
that is in the 128MB prior to vm_taddr.   furthermore, suppose that memory
is already fully allocated.   what will happen?   since the area before
the text is full, the mmap code will skip to the next hole.   where is
the next hole?   --- it is the start of the heap/malloc area.   the next
time sbrk is called to grow the heap it will blow away the mapping you
just established (sys_obreak uses MAP_FIXED).   i think that's bad.


Chuck Cranor                  
Senior Technical Staff Member
Internet and Networking Systems Research Lab
AT&T Labs-Research, Florham Park, NJ