From: Pete Wyckoff <pw@osc.edu>
To: Terry Barnaby <terry@beam.demon.co.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Question on mmap(2) with kernel alocated memory
Date: Sat, 5 May 2001 16:18:19 -0400 [thread overview]
Message-ID: <20010505161819.A8134@quasar.osc.edu> (raw)
In-Reply-To: <3AF2A732.5D4BF81F@beam.demon.co.uk>
In-Reply-To: <3AF2A732.5D4BF81F@beam.demon.co.uk>; from terry@beam.demon.co.uk on Fri, May 04, 2001 at 01:57:22PM +0100
terry@beam.demon.co.uk said:
> I am trying to mmap() into user space a kernel buffer and am having
> problems.
> I have a simple test example, can someone please tell me what I have got
> wrong ?
>
> In a driver I do:
> uint* kva;
>
> kva = (uint*)kmalloc(4096, GFP_KERNEL);
> *kva = 0x11223344;
> printk("Address: %p %lx %x\n", kva, virt_to_phys(kva), *kva);
>
> Now in some simple user program I do:
>
> #include <stdio.h>
> #include <string.h>
> #include <stdlib.h>
> #include <sys/mman.h>
> #include <fcntl.h>
>
> int main(int argc, char** argv){
> int fm;
> char* p;
> uint* pi;
> uint v;
> uint add = 0x74b000;
>
> if((fm = open("/dev/mem", O_RDWR)) < 0)
> return 1;
>
> p = mmap(0, 128 * 1024 * 1024, PROT_READ|PROT_WRITE, MAP_SHARED, fm,
> 0);
> printf("Mapped: %p\n", p);
>
> lseek(fm, add, SEEK_SET);
> read(fm, &v, sizeof(v));
> printf("V: %x\n", v);
>
> pi = (uint*)(p + add);
> printf("Vmmap: %p %x\n", pi, *pi);
>
> close(fm);
> return 0;
> }
>
> The value of add is hardcoded to the value printed for the physical
> address in the drivers prink routine.
> The lseek/read from the /dev/mem device yields the value 0x11223344.
> However the mmap method also on /dev/mem yields the value 0.
>
> Whats wrong with my mmap() or kalloc() ?
Executive summary:
mmap of /dev/mem gives different values than lseek/read of /dev/mem
Using lseek/read gives back bits of physical memory, but dereferencing
a pointer into the mmaped area mostly gives zeroes.
The file-system specific mmap routine, mmap_mem, calls
remap_page_range to do the work of remapping the physical pages
into user space. But eventually in remap_pte_range there's a check
if ((!VALID_PAGE(page)) || PageReserved(page))
set_pte(pte, mk_pte_phys(phys_addr, prot));
And the effect is that only the reserved pages and those outside
of the physical memory space get mapped. This isn't intuitive for
/dev/mem, but is it the intended behavior?
You could replicate those 80 odd lines of remap_page_range and helpers
to get a version without the PageReserved test. Yuk.
Quick hack:
SetPageReserved(virt_to_page(kva));
but you may want to undo that (Clear...) before kfree-ing the page,
as I'm not sure what will be confused by that.
Longer term solution: write your own mmap routine in the driver,
have the user code open /dev/my-driver, and mmap() on that instead
of going through /dev/mem with a hardcoded address.
-- Pete
prev parent reply other threads:[~2001-05-05 20:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-04 12:57 Question on mmap(2) with kernel alocated memory Terry Barnaby
2001-05-05 20:18 ` Pete Wyckoff [this message]
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=20010505161819.A8134@quasar.osc.edu \
--to=pw@osc.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=terry@beam.demon.co.uk \
/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