Messages in this thread | | | Date | Tue, 3 Feb 2009 17:10:08 +0000 (GMT) | From | Hugh Dickins <> | Subject | Re: [PATCH] Fix OOPS in mmap_region() when merging adjacent VM_LOCKED file segments |
| |
On Tue, 3 Feb 2009, Lee Schermerhorn wrote: > On Sat, 2009-01-31 at 12:35 +0000, Hugh Dickins wrote: > > We need a way to communicate not-MAP_NORESERVE to shmem.c, and we don't > > just need it in the explicit shmem_zero_setup() case, we also need it > > for the (probably rare nowadays) case when mmap() is working on file > ^^^^^^^^^^^^^^^^^^^^^^^^ > > /dev/zero (drivers/char/mem.c mmap_zero()), rather than using MAP_ANON. > > > This reminded me of something I'd seen recently looking > at /proc/<pid>/[numa]_maps for <a large commercial database> on > Linux/x86_64: >... > 2adadf711000-2adadf721000 rwxp 00000000 00:0e 4072 /dev/zero > 2adadf721000-2adadf731000 rwxp 00000000 00:0e 4072 /dev/zero > 2adadf731000-2adadf741000 rwxp 00000000 00:0e 4072 /dev/zero > > <and so on, for another 90 lines until> > > 7fffcdd36000-7fffcdd4e000 rwxp 7fffcdd36000 00:00 0 [stack] > ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso] > > For portability between Linux and various Unix-like systems that don't > support MAP_ANON*, perhaps? > > Anyway, from the addresses and permissions, these all look potentially > mergeable. The offset is preventing merging, right? I guess that's one > of the downsides of mapping /dev/zero rather than using MAP_ANONYMOUS? > > Makes one wonder whether it would be worthwhile [not to mention > possible] to rework mmap_zero() to mimic MAP_ANONYMOUS...
That's certainly an interesting observation, and thank you for sharing it with us (hmm, I sound like a self-help group leader or something).
I don't really have anything to add to what Linus said (and hadn't got around to realizing the significance of the "p" there before I saw his reply).
Mmm, it's interesting, but I fear to add more hacks in there just for this - I guess we could, but I'd rather not, unless it becomes a serious issue.
Let's just tuck away the knowledge of this case for now.
Hugh
| |