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

[Eric W. Biederman]

Vivek Goyal <vgoyal@xxxxxxxxxx> writes:

> Hi Eric,
> 
> 
> However for the primary kernel it has no need to know that we
> > even have a backup region, nor does it need to know about the
> > size of the backup region.  That can all be handled with the single
> > reservation, we have now.  
> > 
> > /sbin/kexec which makes the backup needs to know about it and it needs
> > to pass that information on.  But the primary kernel does not. 
> 
> 
> Agreed. Primary kernel need not to be aware of backup region and 
> reservation of this region can be better managed from user space.

Good.  It sound like we are pretty much back on the same page then.

> > > Boot time parameter crashbackup=A@B has been provided to pass this
> > > information to capture kernel. This parameter is valid only for capture
> > > kernel and becomes effective only if CONFIG_CRASH_DUMP is enabled.
> > 
> > But that is not what you implemented.  crashbackup= was an alternative
> > to the carving out of 640K in parts 1-3.
> 
> 
> Not really. crashbackup= is not being used for carving out backup
> region. It is just used for passing the address of this region to second
> kernel. That's why it has been put under CONFIG_CRASH_DUMP.

Ok I missed a piece in your patch.  You have crashdumpk_res, and
crashbackup_start, crashbackup_end.   And I missed the fact that
they were different variables as they dealt with the same concept.

So that patch actually should have been three patches.  The
one line bug fix.  The crashdumpk_res bit (which I strongly
object to) and the crashbackup_start/_end bit.  The fact
that all three were in the same patch is a reviewing and maintenance
pain.

Please in the future do not include code that runs in the primary
kernel and crashdump specific code that runs in the capture kernel in
the same patch.

> This looks good. So memory regions are parsed from /proc/iomem and this
> information is put in one data segment and stored in reserved region
> during panic kernel load time.
> 
> But I am unable to co-relate as to how the capture tool (even if its all
> in user space) gets to know the address of this segment (or for that
> matter, the bss segment created for backup region). Am I missing
> something obvious.

There are a lot of choices at that point.
Place the data in the on the kernel command line, and pick
it up from /proc/cmdline.
Place the data in a file on the initramfs.
Place the data in a user space data segment.


> > However as long as we gracefully handle the interface
> > between the primary kernel and the capture kernel we can
> > switch mechanisms for actually taking the crash dump,
> > kernel based or user space as seems most sane.
> 
> 
> This seems to be a good direction.

Cool.

One of the ideas worth exploring is to see about stabilizing the
other side of this interface as well.   That is we should explore
providing a fixed interface coming out of purgatory.ro to the new
kernel and it's user space (i.e. the ELF header like thing).  I think
we are quite close to that point already.  And this goes back to your
question of how do we let the capture kernel/user space know where to
look.

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/