funny mmap() behaviour + FIX

Christian Groessler (cpg@aladdin.de)
Thu, 24 Sep 1998 00:22:47 +0200


Hi Linus + all,

for those who didn't read my last post a few days ago (the response
wasn't very overwhelming...), again the problem:

I do the following mappings:

#define MAP_ADDR 0xfd000000 /* high mem area, eg. framebuf */
#define MAP_SIZE 0x200000
map_a=mmap(0,MAP_SIZE,PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS,-1,0);
map_b=mmap(0,MAP_SIZE,PROT_READ | PROT_WRITE,
MAP_SHARED,dev_mem_fd,MAP_ADDR);
map_c=mmap(map_a,MAP_SIZE,PROT_READ | PROT_WRITE,
MAP_SHARED | MAP_FIXED,proc_self_mem_fd,
map_b);

When doing the map_c mapping, 2.1.1xx kernels put the process into
jail (D-state) and 2.0.x kernels oops or become inconsistent (unable
to start new processes etc.). It depends a little bit on the MAP_ADDR,
YMMV.

The reason is, that the mem_mmap() function in fs/proc/mem.c accesses
the mem_map table with a mapnr out of range.

I did this fix with my very little VM/paging knowledge, so there might
be a better one. At least it fixes the crashes and the annoying
D-state behaviour.

Please include it into the main tree. Thanks.

regards,
chris

--------------------------------------------------------
--- linux-2.1.122/fs/proc/mem.c.org Thu Sep 17 12:23:47 1998
+++ linux-2.1.122/fs/proc/mem.c Wed Sep 23 23:14:22 1998
@@ -215,7 +215,7 @@
pgd_t *src_dir, *dest_dir;
pmd_t *src_middle, *dest_middle;
pte_t *src_table, *dest_table;
- unsigned long stmp, dtmp;
+ unsigned long stmp, dtmp, mapnr;
struct vm_area_struct *src_vma = NULL;
struct inode *inode = file->f_dentry->d_inode;

@@ -296,7 +296,9 @@

set_pte(src_table, pte_mkdirty(*src_table));
set_pte(dest_table, *src_table);
- atomic_inc(&mem_map[MAP_NR(pte_page(*src_table))].count);
+ mapnr=MAP_NR(pte_page(*src_table));
+ if (mapnr < max_mapnr)
+ atomic_inc(&mem_map[mapnr].count);

stmp += PAGE_SIZE;
dtmp += PAGE_SIZE;
--------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/