Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263396AbVBCN4c (ORCPT ); Thu, 3 Feb 2005 08:56:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263215AbVBCN4b (ORCPT ); Thu, 3 Feb 2005 08:56:31 -0500 Received: from e33.co.us.ibm.com ([32.97.110.131]:47234 "EHLO e33.co.us.ibm.com") by vger.kernel.org with ESMTP id S263123AbVBCN4E (ORCPT ); Thu, 3 Feb 2005 08:56:04 -0500 Subject: Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps. From: Vivek Goyal To: "Eric W. Biederman" Cc: Andrew Morton , fastboot , lkml , Maneesh Soni , Hariprasad Nellitheertha , suparna bhattacharya In-Reply-To: References: <1106294155.26219.26.camel@2fwv946.in.ibm.com> <1106305073.26219.46.camel@2fwv946.in.ibm.com> <1106475280.26219.125.camel@2fwv946.in.ibm.com> <1106833527.15652.146.camel@2fwv946.in.ibm.com> <1106917583.15652.234.camel@2fwv946.in.ibm.com> <1107271039.15652.839.camel@2fwv946.in.ibm.com> <1107338864.11609.35.camel@2fwv946.in.ibm.com> Content-Type: text/plain Organization: Message-Id: <1107442055.11609.191.camel@2fwv946.in.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 03 Feb 2005 20:17:36 +0530 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3225 Lines: 74 On Wed, 2005-02-02 at 21:12, Eric W. Biederman wrote: > Vivek Goyal writes: > > > On Tue, 2005-02-01 at 20:56, Eric W. Biederman wrote: > > > Vivek Goyal writes: > > > > "elfcorehdr=" also looks good. > > Then let's go with that for now. It is not perfect but it seems > a little more self explanatory at first glance. > > > A clarification on terminology we are talking about struct Elf64_Phdr > > > here. There is only one Elf header. That seems to be clear farther > > > down. > > > > > > > > > Exactly. There shall be one Elf header for whole of the image. In > > addition there will be one struct Elf64_Phdr, per contiguous physical > > memory area. One Elf64_Phdr of PT_NOTE type for notes section and one > > Elf64_Phdr for backup region. > > Actually if we are just pointing a kernel data structures we will > need multiple Elf64_Phdr of PT_NOTE. Each cpu has it's own > notes section and until the smoke clears we can't be confident > about what is going to wind up there or how densely those will > be packed. So collapsing everything into a single notes segment > needs to happen after we have switched to the crash capture kernel. Sounds good. So there shall be a PT_NOTE type program header per cpu. And these headers can be collapsed into one PT_NOTE type header later. > > > > I have serious concerns about the kernel generating the ELF headers > > > and only delivering them after the kernel has crashed. Because > > > then we run into questions of what information can be trusted. If we > > > avoid that issue I am not too concerned. > > > > > > I hope, all elf headers once prepared by kexec-tools need not to change > > later (Cannot think of any piece of information which shall change > > later). These shall be put in separate segment. And SHA-256 shall take > > care of authenticity of information after crash. > > That should work fine. We need to consider through throwing in an > extra note section with information like kernel version that > we can capture while the system is running. > > > For notes section program header, virtual = physical = 0 and "offset" > > shall point to crash_notes[], so that notes can directly be read by the > > capture kernel (or user space). > > I agree. But see my caveat. I think we should have one PT_NOTE > segment point at each element of the crash_notes[] array. I know > it is technically a violation of the ELF spec. But in this case > it makes sense. Since we can't guarantee that crash_notes will > be packed properly I don't know that we could reliably see more > than one cpu if we pointed a PT_NOTE header at the whole thing. > > If it turns out that we can reliably point a single PT_NOTE header > at crash_notes so much the better but things are likely to be > more robust if we don't start with that assumption. That > at least allows us the freedom to capture some notes (like NT_UTSNAME) > before the kernel crashes. > > Eric > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/