kdump in upstream kexec-tools

[Simon Horman]

On Wed, Apr 18, 2018 at 07:28:54PM +0100, Russell King wrote:
> On Wed, Apr 18, 2018 at 03:01:08PM +0200, Simon Horman wrote:
> > On Tue, Apr 17, 2018 at 10:01:13AM +0100, Russell King wrote:
> > > On Tue, Apr 17, 2018 at 10:20:08AM +0530, Bhupesh Sharma wrote:
> > > > Hi,
> > > > 
> > > > I was working on improving documentation/structure of the upstream
> > > > kexec-tools and I was wondering what is the purpose of the 'kdump'
> > > > directory inside the kexec-tools.
> > > > 
> > > > This kdump utility seems to cause confusion with the 'kdump' utility
> > > > present inside some distributions (for e.g.  '/usr/sbin/kdump' present
> > > > inside fedora) due to the same naming convention and so we should
> > > > populate/modify the kdump man page to indicate the same, so as to
> > > > avoid confusion.
> > > > 
> > > > Presently here are the contents of this directory:
> > > > 
> > > > # ls kdump/
> > > > kdump.8  kdump.c  Makefile
> > > > 
> > > > - Out of these the kdump man documentation (kdump.8) is just a
> > > > placeholder as suggested by the man page documentation: "kdump - This
> > > > is just a placeholder until real man page has been written"
> > > > 
> > > > - Looking at kdump.c :
> > > > 
> > > > 1. I understand that this code is mainly used to read a crashdump from
> > > > memory. One can run the same using:
> > > > 
> > > > # kdump <start_addr>
> > > > 
> > > > where start_addr is basically the start address of the core dump
> > > > (which can also be represented via the 'elfcorehdr' environment
> > > > variable being passed to the crash kernel which represents the
> > > > physical address of the start of the ELF header)
> > > > 
> > > > 2. This tool needs READ_ONLY access to /dev/mem (so we need to set
> > > > CONFIG_STRICT_DEVMEM configuration option accordingly).
> > > > 
> > > > 3. The code thereafter reads (via mmap) and verifies the ELF header.
> > > > Subsequently it reads (via mmap) the program header.
> > > > 
> > > > 4. Then we collect all the notes and write on STDOUT all the headers
> > > > and notes found in the crashdump collected from memory.
> > > > 
> > > > So, as per my understanding even in absence of (more powerful) tools
> > > > like crash (or gdb), we can still go ahead and read the crashdump from
> > > > memory and display all the headers and notes present in the same on
> > > > standard serial out interface using this kdump utility.
> > > > 
> > > > This is probably a good to have feature for systems which have very
> > > > simple/minimal rootfs (and I see that a few arm32 systems seem to use
> > > > the same as well) or are low on memory availability.
> > > > 
> > > > Now, I wanted to confirm if the 'kdump' utility for reading crashdump
> > > > collected from memory is still needed (as the last commit is dated
> > > > back to 2016 and was done for arm32 systems). If yes, I can go ahead
> > > > and enhance the kdump man page to include the description given above
> > > > - so that it helps users understand how to run the tool.
> > > > 
> > > > Please share your opinions.
> > > 
> > > Firstly, please use:
> > > 
> > >   git://git.armlinux.org.uk/~rmk/kexec-tools.git
> > > 
> > > for ARM systems - this has some important fixes that aren't in the
> > > mainline repository.
> > 
> > I apologise if this is due to omission on my part,
> > can we work towards getting them in the mainline repository?
> 
> The problem on ARM was caused because you applied the wrong version of
> the patches I sent out.  When I noticed and reported it, there was no
> response.
> 
> My only option over that intervening six months is to provide people
> with something that actually works properly on 32-bit ARM has been
> to publish my own kexec-tools git tree with the appropriate fixes in.
> 
> It now contains a couple more patches than just fixing that up.
> 
> If you want to merge from the above URL, be my guest, but as far as
> I'm concerned, it's been proven that sending patches for merging is
> open to mistakes happening.  That wouldn't be too bad if it hadn't
> taken more than six months to get your attention on this issue.

Thanks, pulled.