linux-mips
[Top] [All Lists]

Re: User/Group Problem

To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Subject: Re: User/Group Problem
From: Ralf Baechle <ralf@oss.sgi.com>
Date: Wed, 15 Nov 2000 08:52:45 +0100
Cc: Ian Chilton <ian@ichilton.co.uk>, linux-mips@oss.sgi.com, lfs-discuss@linuxfromscratch.org, Andreas Jaeger <aj@suse.de>
In-reply-to: <Pine.GSO.3.96.1001114150916.17140A-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Tue, Nov 14, 2000 at 03:19:11PM +0100
References: <20001113231949.B16012@bacchus.dhis.org> <Pine.GSO.3.96.1001114150916.17140A-100000@delta.ds2.pg.gda.pl>
Sender: owner-linux-mips@oss.sgi.com
On Tue, Nov 14, 2000 at 03:19:11PM +0100, Maciej W. Rozycki wrote:

> > There is second interpretation of this problem - the address passed to
> > mmap is bogus, so this computation needs to be fixed.
> 
>  Where is it written mmap() is allowed to fail when a bogus VM address is
> passed but MAP_FIXED is not set?  I believe mmap() should choose a
> different VM address in this case, as long as much enough contiguous VM
> space is available anywhere to satisfy the requested length.

No argument about that, I do agree.

>  Surely, map_segment() (see dl-load.c) might call mmap(0, ...) after
> mmap(<some_address>, ...) fails when MAP_FIXED is not set but wouldn't
> that be a dirty hack?  We'd better fix the kernel. 

Ld.so isn't linked to the same base address as all other libraries for
obscure reasons.  Right now dl-machine.h use the constant value of 0x5ffe0000
as the base address which it assumes all libraries to be linked to - and that
makes us calculate the wrong base address which we're passing to mmap.

So we've got two bugs, not just one.  I knew about the ld.so part since
Linux/MIPS has shared libs.  It's just that this is the first time this bug
bites us.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>