linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mpeg.blue@free.fr (Mason)
To: linux-arm-kernel@lists.infradead.org
Subject: ioremap vs remap_pfn_range, VMSPLIT, etc
Date: Fri, 09 Jan 2015 13:59:10 +0100	[thread overview]
Message-ID: <54AFD09E.1010806@free.fr> (raw)

Hello everyone,

Yesterday, I used /dev/mem to mmap 2 GB and (to my surprise) it worked.
Specifically, I opened /dev/mem O_RDWR | O_SYNC
then called
  mmap(NULL, 1U<<31, PROT_WRITE, MAP_SHARED, fd, 0x80000000);

And mmap returned a valid pointer.

I was expecting it to fail.

- the kernel is configured with VMSPLIT_3G (3G/1G user/kernel)
- the kernel manages 256 MB RAM
- there is roughly 750 MB of VMALLOC space, no highmem

I know /dev/mem's mmap calls remap_pfn_range, but I was expecting
the VMALLOC space to impose a limit on the size of the mapping.
Obviously this was incorrect?

If I requested the same mapping *within the kernel* using ioremap,
would that fail because of limited VMALLOC space?

Moving to arch-specific questions (namely ARM Cortex-A9).
If I understand correctly (which is very possibly NOT the case)
the CPU has two registers pointing to page tables, one for
the current process, one for the kernel. And the CPU automatically
picks the correct one, based on the active context?
It would seem possible to have a full 4G for process, and a full 4G
for the kernel, using that method, no? (Like Ingo's old 4G/4G split).
Without the performance overhead of fiddling with the page tables.
What am I missing?

Regards.

             reply	other threads:[~2015-01-09 12:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-09 12:59 Mason [this message]
2015-01-09 13:13 ` ioremap vs remap_pfn_range, VMSPLIT, etc Russell King - ARM Linux
2015-01-09 17:46   ` Mason
2015-01-09 18:06     ` Vladimir Murzin
2015-01-09 18:42       ` Mason
2015-01-09 19:05     ` Russell King - ARM Linux

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=54AFD09E.1010806@free.fr \
    --to=mpeg.blue@free.fr \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).