[RFC][PATCH] reduce default MAX_MAP_COUNT to be safe value

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

I posted a question about this to gdb people but get no answers ;)
Then, start from what I can do, now.

Opinions ?

Thanks,
-Kame
==
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

With ELF, at generating coredump, some more headers other than used vmas
are added.
When, maxp_map_count == 65536, a core generated by following kinds of
code can be unreadable because the number of ELF's program header is
written in 16bit in Ehdr (please see elf.h) and the number overflows.
==
	... = mmap(); (munmap, mprotect, etc...)
	if (failed)
		abort();
==
This can be happen in mmap/munmap/mprotect/etc...which calls
split_vma().

I think 65536 is not safe as _default_ because core-dump can be
corrupted when we need to look into coredump.
This reduce it to 65500 for avoiding unexpected corrupted core.
(I confirmed 65530 can work well with my tiny program.)

Anyway, max_map_count can be enlarged by sysctl if a user is brave..

Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
---
 include/linux/sched.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.30.org/include/linux/sched.h
===================================================================
--- linux-2.6.30.org.orig/include/linux/sched.h
+++ linux-2.6.30.org/include/linux/sched.h
@@ -350,7 +350,7 @@ struct nsproxy;
 struct user_namespace;
 
 /* Maximum number of active map areas.. This is a random (large) number */
-#define DEFAULT_MAX_MAP_COUNT	65536
+#define DEFAULT_MAX_MAP_COUNT	65500
 
 extern int sysctl_max_map_count;
 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>