From: Richard Mortimer <richm@oldelvet.org.uk>
To: sparclinux@vger.kernel.org
Subject: Re: mmap breakage
Date: Sat, 04 Dec 2004 23:13:00 +0000 [thread overview]
Message-ID: <1102201980.15654.108.camel@duncow> (raw)
In-Reply-To: <Pine.LNX.4.61.0412032354010.1963@bobcat>
On Sat, 2004-12-04 at 05:22, Jurij Smakov wrote:
> Hello,
>
> In Debian we have recently received a number of bug reports [0,1] about
> glibc's ld-linux.so.2 failing (when called via ldd, for example) on some
> binaries. The minimum test case, originally mentioned in [0], was the
> following:
>
>
Well I can demonstrate the behaviour (see attached test program) on sparc64 and i386. It allows mappings to be fully or partially replaced and even allows you to replace bits in the middle of a mapping.
Now the bad news...
This seems to be POSIX defined behaviour
http://www.opengroup.org/onlinepubs/009695399/functions/mmap.html
Specifically
"The mapping established by mmap() shall replace any previous mappings
for those whole pages containing any part of the address space of the
process starting at pa and continuing for len bytes."
and more specifically when MAP_FIXED is supplied
"If a MAP_FIXED request is successful, the mapping established by mmap()
replaces any previous mappings for the process' pages in the range
[pa,pa+len)."
and
"On the other hand, if the program specifies a fixed address mapping
(which requires some implementation knowledge to determine a suitable
address, if the function is supported at all), then the program is
presumed to be successfully managing its own address space and should be
trusted when it asks to map over existing data structures."
I guess that this isn't really what you want to hear but it does
describe why the behaviour exists. I don't have any magic suggestions as
to how to fix it - sorry.
Richard
P.S. You can see the overwriting of mappings if you look at
/proc/<pid>/maps. You will see that the second mapping has totally
superceded the first and the third mapping has split the second one up.
01000000-01002000 rw-p 00000000 00:0b 8 /dev/zero
01002000-01004000 rw-p 00000000 03:02 863336 /var/log/messages
01004000-01020000 rw-p 00004000 00:0b 8 /dev/zero
--
richm@oldelvet.org.uk
next prev parent reply other threads:[~2004-12-04 23:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-04 5:22 mmap breakage Jurij Smakov
2004-12-04 23:13 ` Richard Mortimer [this message]
2004-12-04 23:16 ` Richard Mortimer
2004-12-06 4:30 ` Jurij Smakov
2004-12-06 5:23 ` David S. Miller
2004-12-07 6:00 ` Jurij Smakov
2004-12-07 6:06 ` David S. Miller
2004-12-07 6:11 ` Keith M Wesolowski
2004-12-07 6:20 ` David S. Miller
2004-12-07 6:31 ` Jurij Smakov
2004-12-07 7:47 ` David S. Miller
2004-12-07 8:24 ` Jakub Jelinek
2004-12-07 15:38 ` Jurij Smakov
2004-12-08 0:54 ` Richard Mortimer
2004-12-09 5:24 ` David S. Miller
2004-12-09 7:34 ` David S. Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1102201980.15654.108.camel@duncow \
--to=richm@oldelvet.org.uk \
--cc=sparclinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.