Re: load_region() patch

[hohmuth@inf.tu-dresden.de (Michael Hohmuth)]

Hi there!

I'm currently in the process of putting together mh-mint 1.12h3.

Did anyone actually try the following patch?  I'm unsure about whether
I should include it in the release.  (For now, I've just applied
Torsten's quick fix from
<9412271723.AB05363@kassandra.techfak.uni-bielefeld.de>).

Thanks,
Michael

Juergen Lock wrote:
> 
> In article <9412271723.AB05363@kassandra.techfak.uni-bielefeld.de> you write:
> > Ok, looks like I've got it. Puuuuhhhh... :)
> 
> hmm looks like my test-patch mail hung again...  did you get it now?
> >
> > To describe what's going on: At the beginning of create_base() in mem.c the
> >maximum available memory size `len' is determined plus the map where to find
> >it. If this does not fit to the program wanting to be loaded into alternate
> >ram it is set to core memory immediately.
> >
> > Now comes a thing which I don't unterstand: When actually allocating memory
> >from this map later `normal' programs always allocate `len' bytes, but shared
> >text programs allocate `len + fh->ftext + KERNEL_MEM'.
> 
>  shared text programs whose text is not yet loaded actually...  and
> KERNEL_MEM is only spare in case the text loading etc. needs a new
> nalloc arena.
> 
> > Don't whow where the
> >point of making is that difficult is, but normally it works because some
> >lines earlier `len' is decremented by exactly `fh->ftext + KERNEL_MEM' bytes
> >for all shared text programs.
> >
> > This decrementing is bound to some conditions dealing with alternate memory,
> 
>  yep, that the text cannot go in the other map...  (think of gcc-cc1...)
> 
> >and here comes the crack: None of this condition must necessary be true if
> >the program is too large to fit into alternate memory and therefore all
> >lengths and maps are set up to deal with core memory already. Thus this
> >decrementation will never happen and thus when allocating the memory `fh->
> >ftext + KERNEL_MEM' will be be added again, resulting in a request bigger
> >than the largest block and thus fail. :(
> 
>  and this was missing: to actually try placing the text in the other
> map later... :/  (and another sanity check.)
> 
> Index: mem.c
> @@ -1170,6 +1170,13 @@
>  /* make sure that a little bit of memory is left over */
>  	if (len > 2*KEEP_MEM) {
>  		len -= KEEP_MEM;
> +	} else if (s && !s->text &&
> +	    (!(flags & F_ALTLOAD) || map == alt || altsize < fh->ftext)) {
> +		len = 0;
> +		if (!ismax) {
> +			ismax = -1;
> +			goto again1;
> +		}
>  	}
>  
>  	if (s && !s->text &&
> @@ -1252,14 +1259,21 @@
>  	if (s && !s->f) {
>  		if (!s->text) {
>  			m = addr2mem(alloc_region(map, len + fh->ftext + KERNEL_MEM, protmode));
> -			if (!m ||
> -			    (((len > minalt &&
> -				((flags & F_MINALT) < F_MINALT) &&
> -				max_rsize (map, -1) < fh->ftext) ||
> -			      0 == (s->text = addr2mem(alloc_region(map, fh->ftext, PROT_P))) ||
> -			      (m->next == s->text &&
> -				!(detach_region (curproc, s->text), s->text = 0))) &&
> -			     shrink_region(m, fh->ftext))) {
> +			if (!m && (flags & F_ALTLOAD)) {
> +				if (map == core && altsize >= fh->ftext)
> +				      s->text = addr2mem(alloc_region(alt, fh->ftext, PROT_P));
> +				else if (map == alt && coresize >= fh->ftext)
> +				      s->text = addr2mem(alloc_region(core, fh->ftext, PROT_P));
> +			}
> +			if (!s->text &&
> +			    (!m ||
> +			      (((len > minalt &&
> +				 ((flags & F_MINALT) < F_MINALT) &&
> +				 max_rsize (map, -1) < fh->ftext) ||
> +				0 == (s->text = addr2mem(alloc_region(map, fh->ftext, PROT_P))) ||
> +				(m->next == s->text &&
> +				 !(detach_region (curproc, s->text), s->text = 0))) &&
> +			       shrink_region(m, fh->ftext)))) {
>  				if (m)
>  					detach_region(curproc, m);
>  				kfree (s);
> 
>  (warning i cannot test this, which is why i sent it to you first :)
> >
> > I'm a bit worried why things look so strange and much more difficult than I
> >would have expected them to be, which is why I don't really want to judge
> >about all this decrementing and adding and why these conditions dealing with
> >alternate memory ...
> 
>  well thats what you pay when you have to cram all processes in one
> address space, a 1000 kludges...
> 
>  anyway have fun,
> 	Juergen
> 
> 


-- 
Email: hohmuth@inf.tu-dresden.de
WWW:   http://www.inf.tu-dresden.de/~mh1/