Re: [Fastboot] [PATCH] Reserving backup region for kexec basedcrashdumps.

[Vivek Goyal]

On Wed, 2005-02-02 at 21:12, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@xxxxxxxxxx> writes:
> 
> > On Tue, 2005-02-01 at 20:56, Eric W. Biederman wrote:
> > > Vivek Goyal <vgoyal@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/