Messages in this thread |  | | Date | Fri, 26 Oct 2001 20:25:35 +0200 (MET DST) | From | "Maciej W. Rozycki" <> | Subject | Re: alpha 2.4.13: fix taso osf emulation |
| |
On Fri, 26 Oct 2001, Richard Henderson wrote:
> > The following trivial patch reportedly fixes OSF/1 programs using 31-bit > > addressing. It's already present in the -ac tree; I guess it just got > > lost during a merge. It applies fine to 2.4.13. > > This is the patch that Jay Estabrook forwarded me that I rejected > in favour of writing a special arch_get_unmapped_area.
Ah, that is a fine approach as well; I just considered the change small enough it's not worth making it arch-specific. Besides, my patch alsoo has a small advantage of keeping the search algorithm the same across all the archs.
> > It used to do so. It breaks things such as dynamic linking of shared > > objects linked at high load address. > > Err, how?
I mean, the original algorithm as implemented in 2.4.9. If you had asked e.g. for memory above TASK_SIZE you would have got an error no matter how much address space was still available below.
> > It breaks mmap() in principle, as it shouldn't fail when invoked with > > a non-zero, non-MAP_FIXED, invalid address if there is still address > > space available elsewhere. > > No, it doesn't. Or rather, it only does if you only bothered > to search once. IMO one should search thrice: once at addr, > once at TASK_UNMAPPED_BASE, and once at PAGE_SIZE.
OK, but I'd prefer to avoid searching overlapping areas over and over again for performance's sake. My solution does a single lookup and a single search, effectively covering at least the whole space that would be used if no address preference was specified; more if a program asked for space below TASK_UNMAPPED_BASE (= "yes, I know what I'm doing, I want to limit my brk() space").
-- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |