From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail137.messagelabs.com (mail137.messagelabs.com [216.82.249.19]) by kanga.kvack.org (Postfix) with SMTP id A4A5F6B005A for ; Fri, 12 Jun 2009 03:02:02 -0400 (EDT) Received: from m3.gw.fujitsu.co.jp ([10.0.50.73]) by fgwmail7.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id n5C722xV015801 for (envelope-from kamezawa.hiroyu@jp.fujitsu.com); Fri, 12 Jun 2009 16:02:02 +0900 Received: from smail (m3 [127.0.0.1]) by outgoing.m3.gw.fujitsu.co.jp (Postfix) with ESMTP id D719045DD7B for ; Fri, 12 Jun 2009 16:02:01 +0900 (JST) Received: from s3.gw.fujitsu.co.jp (s3.gw.fujitsu.co.jp [10.0.50.93]) by m3.gw.fujitsu.co.jp (Postfix) with ESMTP id A596545DD7D for ; Fri, 12 Jun 2009 16:02:01 +0900 (JST) Received: from s3.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 3C49C1DB8041 for ; Fri, 12 Jun 2009 16:02:01 +0900 (JST) Received: from m108.s.css.fujitsu.com (m108.s.css.fujitsu.com [10.249.87.108]) by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id D33521DB8042 for ; Fri, 12 Jun 2009 16:02:00 +0900 (JST) Date: Fri, 12 Jun 2009 16:00:29 +0900 From: KAMEZAWA Hiroyuki Subject: [RFC][PATCH] reduce default MAX_MAP_COUNT to be safe value Message-Id: <20090612160029.61dcaed4.kamezawa.hiroyu@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: "linux-mm@kvack.org" Cc: "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" List-ID: 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 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 --- 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: email@kvack.org