From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: [PATCH 1/1] x86: Add process memory layout to coredump file Date: Sat, 10 Dec 2011 12:02:39 -0800 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org To: t cheney Return-path: Received: from mga02.intel.com ([134.134.136.20]:43066 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751187Ab1LJUCr (ORCPT ); Sat, 10 Dec 2011 15:02:47 -0500 In-Reply-To: (t. cheney's message of "Sat, 10 Dec 2011 22:37:02 +0800") Sender: linux-fsdevel-owner@vger.kernel.org List-ID: t cheney writes: > This patch just add memory layout(same as /proc/pid/maps) to > coredump file. The layout is appended to corenote segment with > flag NT_MAPS=7. Seems like a reasonable idea, but can you please share code with the proc implementation? It's a bit unusal to have ASCII in a coredump, but I suppose expressing this in binary would be somewhat ugly. > + char *buf = notes->data; > + size_t core_limit = notes->datasz; > + gate_vma = get_gate_vma(current->mm); > + It seems a bit dubious to do this without locking even in a core dump. > + for (vma = first_vma(current, gate_vma); vma != NULL; > + vma = next_vma(vma, gate_vma)) { > + flags = vma->vm_flags; > + maps_size += len; > + if (file) { > + if (maps_size > core_limit) > + break; You have a one-off bug here. Also below. > + DUMP_WRITE(buf, len, foffset); > + } -Andi -- ak@linux.intel.com -- Speaking for myself only