Reproducible Oops in 2.0.24...

Johnny Stenback (jst@uwasa.fi)
Thu, 7 Nov 1996 14:22:09 +0200 (EET)


Hi

I just discovered a reproducible Oops in 2.0.24, it has to do with
mmap. I just tried for the first time in my life to write a program
that uses mmap and I screwed up (of course), I got it working when I
tried to "read" from a file but then I wanted to "write" to the
mmapped pointer and it didn't work right away (probably some stupid
mistake, or?). OK, I played around some more and ended up with the
following C code:

#include <stdio.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>
#include <errno.h>

void main ()
{
int fd;
void *p;
char buf[1024];

fd = open("test", O_RDONLY);

p = mmap(NULL, 200, PROT_WRITE, MAP_PRIVATE, fd, 0);

strncpy (buf, p, 100);

printf ("%s\n", buf);

munmap (p, 200);

exit (0);
}

As you can see, this is wrong, I mmap with PROT_WRITE and try to read
from the pointer. When I compile this and run it I get an Oops the
first time I run it, the second time it just hangs (and can't be
killed), if I reboot and try again I get the same result. I tried this
on 2.0.23 and got the same result and I also tried with 2.0.7 and
there it just said something like "Exeption xxxxxxx at xxxxxxx" (sorry
don't remember exactly, can check tonight though if it's important).
Here's the Oops I get with 2.0.24:

Unable to handle kernel paging request at virtual address 40007000
current->tss.cr3 = 003ea000, Lr3 = 003ea000
*pde = 011d3067
*pte = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[__generic_memcpy_fromfs+56/232]
EFLAGS: 00010212
eax: 00f15bf4 ebx: 00000004 ecx: 00000400 edx: 00000400
esi: 40007000 edi: 010ac800 ebp: 00000000 esp: 0094db80
ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
Process a.out (pid: 3316, process nr: 32, stackpage=0094d000)
Stack: 40007000 00009000 00000000 00000018 00000024 017d16c8 00000002 00efd460
0014c808 017d16c8 01d07d48 00000018 00000001 00000400 00000024 0094dc40
017d16c8 0000000c 00000001 00000024 0094dc40 00000024 00009000 00000000
Call Trace: [ext2_getblk+260/556]
[ext2_file_write+377/1092]
[ext2_file_write+568/1092]
[do_truncate+70/120]
[do_truncate+90/120]
[permission+32/208]
[dump_write+28/44]
[writenote+167/200]
[dump_write+28/44]
[elf_core_dump+2360/2508]
[<02985800>]
[do_no_page+259/736]
[do_page_fault+283/724]
[do_no_page+0/736]
[do_page_fault+0/724]
[do_signal+495/636]
[signal_return+18/64]
Code: 64 8b 06 26 8b 07 9b dd 74 24 0c b8 04 00 00 00 64 df 6e 00

Code: 00000000 <_EIP> movl %fs:(%esi),%eax
Code: 00000003 <_EIP+3> movl %es:(%edi),%eax
Code: 00000006 <_EIP+6> fsave 0xc(%esp,1)
Code: 0000000b <_EIP+b> movl $0x4,%eax
Code: 00000010 <_EIP+10> fildll %fs:0x0(%esi)
Code: 00000014 <_EIP+14>

I tried to find out where the bug (?) is myself but I failed to find
it and I don't have the knowledge nor time to dig any deeper...

-- 
Johnny Stenback, programmer / University of Vaasa, Computer Centre 
E-Mail jst@uwasa.fi, Phone +358 50 5575 094