public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: R.E.Wolff@BitWizard.nl (Rogier Wolff)
Cc: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: mmap not working?
Date: 17 Nov 2001 11:47:31 -0700	[thread overview]
Message-ID: <m1wv0p8cak.fsf@frodo.biederman.org> (raw)
In-Reply-To: <200111170907.KAA24566@cave.bitwizard.nl>
In-Reply-To: <200111170907.KAA24566@cave.bitwizard.nl>

R.E.Wolff@BitWizard.nl (Rogier Wolff) writes:

> I'm not sure wether the kernel has been wrong all the time or if
> something changed recently. I posted the "workaround" the first time
> through, which also works from userspace. I can change my application. 
> I can modify my libc. 
> 
> However, I'd rather have "mmap" fixed, as that fixes it for all other
> applications too. Not just for mine on my system. 
> 
> The SGI manpage says: 
> 
>      All implementations interpret an addr value of
>      zero as granting the system complete freedom in selecting pa, subject to
>      constraints described below.  A non-zero value of addr is taken to be a
>      suggestion of a process address near which the mapping should be placed.
> 
> which hints at a possible non-alignment. It also mentions that
> "offset" should be page-aligned, which I disagree with here:
> everything has been set up to "do the right thing" when the mapping is
> possible with an unaligned offset.

Except there is no way to give you enough information to munmap the page.
As the address passed to munmap must be page aligned.

The current policy appears to make an application think as up front
as possible about the need to be page aligned when talking to mmap,
while not being overly harsh.  We do have the silent rounding
up of length until it is a multiple of PAGE_SIZE.

Beyond this the internal linux implementation of mmap does not even
see the extra bits in the offset.  Instead the most recent syscall
entry point takes an argument as to which page you want to mmap from
the device.  This allows much larger devices to be mmaped while
still using 32bit arithmetic.

So I neither see that it is easy or even desirable to ``fix'' mmap.

Eric

  parent reply	other threads:[~2001-11-17 19:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3BF623B7.1050607@zytor.com>
2001-11-17  9:07 ` mmap not working? Rogier Wolff
2001-11-17 18:38   ` Rik van Riel
2001-11-17 18:47   ` Eric W. Biederman [this message]
2001-11-16 21:34 Rogier Wolff
2001-11-16 22:10 ` H. Peter Anvin

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=m1wv0p8cak.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=R.E.Wolff@BitWizard.nl \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox