[lkml]   [2001]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] Re: Linux 2.4.5-ac6
On Tue, 5 Jun 2001, Ivan Kokshaysky wrote:

> Hmm, yes. However, your patch isn't pretty, too. You may check
> the same area twice, and won't satisfy requested address > TASK_UNMAPPED_BASE.

Only a single address may be checked twice. There is no second loop I'm
trying to avoid. The loop starts from addr or TASK_UNMAPPED_BASE,
whichever is lower. If that won't succeed you won't be able to mmap
anything anyway.

> What do you think about following? Everything is scanned only once, and
> returned address matches specified one as close as possible.

No, no, no... The address specified is a hint only and the system is
free to use any other. Actually this patch made me curious, why we should
change the limit -- TASK_SIZE is fine in all cases. After a bit of
studying of Alpha headers, I concluded none of the patches is needed at
all, because TASK_UNMAPPED_BASE is set to:

((current->personality & ADDR_LIMIT_32BIT) ? 0x40000000 : TASK_SIZE / 2)

to support 32-bit binaries. So if the personality is set appropriately
for netscape, mmap() should work fine as is, placing maps in the low 4GB.
No need to patch arch_get_unmapped_area(), but OSF/1 compatibility code
might need fixing. I suppose an OSF/1 binary must have an appropriate
flag set in its header after building with the -taso option so that the
system knows the binary wants 32-bit addressing.

I have no Alpha/Linux system available anymore -- could anyone else check
what the real problem with netscape is?


+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail:, PGP key available +

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:54    [W:0.119 / U:0.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site