From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422639AbXBPPJd (ORCPT ); Fri, 16 Feb 2007 10:09:33 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1422643AbXBPPJd (ORCPT ); Fri, 16 Feb 2007 10:09:33 -0500 Received: from mx1.redhat.com ([66.187.233.31]:45151 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1422639AbXBPPJc (ORCPT ); Fri, 16 Feb 2007 10:09:32 -0500 From: David Howells In-Reply-To: <45D5B2E3.3030607@hitachi.com> References: <45D5B2E3.3030607@hitachi.com> To: "Kawai, Hidehiro" Cc: Andrew Morton , kernel list , Pavel Machek , Robin Holt , Alan Cox , Masami Hiramatsu , sugita , Satoshi OSHIMA , "Hideo AOKI@redhat" Subject: Re: [PATCH 0/4] coredump: core dump masking support v3 X-Mailer: MH-E 8.0; nmh 1.1; GNU Emacs 22.0.50 Date: Fri, 16 Feb 2007 15:08:54 +0000 Message-ID: <20425.1171638534@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Kawai, Hidehiro wrote: > To avoid the above situation we can limit the core file size by > setrlimit(2) or ulimit(1). But this method can lose important data > such as stack because core dumping is terminated halfway. > So I suggest keeping shared memory segments from being dumped for > particular processes. A better way might be to place the shared memory segments last if that's possible (I'm not sure ELF supports out-of-order segments). > Because the shared memory attached to processes is common in them, we don't > need to dump the shared memory every time. So there's no guarantee that they'll be dumped at all... I'm not sure there's any way around that, however. David