Re: TASK_UNMAPPED_BASE

On Tue, 2004-02-03 at 09:22, Franz Sirl wrote:

At 14:05 03.02.2004, Joakim Tjernlund wrote:

quoted

I changed TASK_UNMAPPED_BASE to well under 0x01fffffc and it worked as well.

My question: Why is TASK_UNMAPPED_BASE=0x30000000 and would changing it to
something less, say 0x00100000 be a problem?

Hmm, might work, but it can also break in subtle ways, cause the shared lib
loading algorithm makes a few assumptions about the used address ranges
IIRC. But I don't see any use for it if you consider what I said above.

I've seen problems with HPC apps/benchmarks with huge bss's that fail to
run because TASK_UNMAPED_BASE is set too low.  I'll admit they fail to
run due to a bug in the fs/binfmt_elf.c, but the fix has never been
accepted yet.  The bug is that we don't reserve the bss region for the
app (via a set_brk/do_brk call) until after we've loaded the loader so
they get mapped to overlapping memory locations.  The fix is to move the
update to current->mm.* and the set_brk/do_brk call to before the point
we call load_elf_interp().

Another bug is that the calls to set_brk/do_brk in fs/binfmt_elf.c fail to
check whether the set_brk/do_brk calls succeeded or not, so they implicitly
assume they do.  With an app with a huge bss, the set_brk/do_brk call actually
returns -ENOMEM which is then ignored.  The fix is to test for failure from
the set_brk/do_brk calls.

Peter


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/