Kernel bug messages with anonymous mmap

Kernel bug messages with anonymous mmap

Post by Saket Saura » Sat, 29 Mar 2003 13:30:26



I am working on an SH4 port of linux. Things that I am doing here
might seem totally unreasonable. But all this is an attempt to
overcome a hardware limitation with SH4, which allows a PCI memory
window of 16MB. In order for applications to be able to transparently
use more than that I need to do the following:

I anonymously mmap 16MB of PCI window memory into the user space using
the following call:
 ptr = mmap((void*)0, 0x01000000, PROT_WRITE | PROT_READ,
                MAP_SHARED|MAP_ANONYMOUS|MAP_PCI, -1, 0);
Within the kernel I use the MAP_PCI flag to call  remap_page_range
from within the kernel and create page tables (I don't know of a
better way to build page tables for this map, please suggest if there
is one)

After this if I dump page tables I see that all mappings have been
correctly created. However, later on when the process makes more calls
to mmap(on other devices) I see the following error.

forget_pte: old mapping existed!
kernel BUG at memory.c:303!

What happens is that the pte_alloc gets a page which was earlier being
used by this anonymous mmap thereby overwriting the entries for the
anonymous mmap. This error happens with some apps and not with others.

On a side note when I see the memory map for this process I see the
anonymous entry as:

29800000-2a800000 rw-s 00000000 00:05 440        /dev/zero (deleted)

Anyone have an idea why the pte_alloc is getting an already used page?

Thanks
Saket Saurabh.

 
 
 

1. mmap not working(2) - kernel bug?!

[ Ispricavam se zbog engleske poruke na hr grupe, ali ne da mi se pisati dva
  clanka / I apologize for English message in Croatian newsgroups, but I'm lazy
  to write 2 articles. ]

So I have resolved my problem (if you have read my previous post about mmap).
It seems that Linux kernel is unable to handle sparse mmaped files. I allocate
the file like this (sz is something like 60MB, the size I need).

if((fd = open(fname, O_CREAT | O_RDWR | O_TRUNC, S_IRUSR | S_IWUSR)) < 0) {
        perror("open");
        exit(1);
if(lseek(fd, sz-1, SEEK_SET) < 0) {
        perror("lseek");
        exit(1);
write(fd, &c, 1);

The program works just fine (no SIGBUS anymore) without any modification
when I make a non-sparse with dd if=/dev/zero of=ACCU.ght bs=1024 size=65536 .
(except opening the file; I removed O_TRUNC from open() flags and lseek/write)

Now, I'd like to know what POSIX says about this? Does it even mention sparse
files or are they just Linux's method of saving disk space? Is this a known
bug? (I can't wait to test it on Monday on 2.4 kernel... :)

Have I stumbled upon a kernel bug and how do I report it?

2. bind fail

3. 0.99pl8 kernel bug -fix (= no kernel bug)

4. DEC Celebris GL-5166st: your thoughts please!

5. No support for SHARED ANONYMOUS mmapping ?

6. REDHAT 5 and PA-2007 motherboard

7. Odd Msg : sort: can't mmap anonymous memory: Resource temporarily unavailable

8. getting bind to work on Solaris 8

9. Odd Msg : sort: can't mmap anonymous memory: Resource temporarily

10. No support for SHARED ANONYMOUS mmapping ?

11. Odd Msg : sort: can't mmap anonymous memory: Resource temporarily unavailable

12. Anonymous shared mmap?

13. anonymous mmap problem