[PATCH 2/2] makedumpfile: make the incomplete vmcore generated by ENOSPC error analyzable

[Dave Anderson]

----- Original Message -----
> Hello Dave,
> 
> Thanks for your reply.
> 
> We can use two methods to indicate that the incomplete vmcore is a "fixed" one,
> 1. Use a flag in elf/kdump dumpfile(like "e_flags" in ELF header and "status"
>     in disk_dump_header) to indicate it has been "fixed". But actually the
>     kdump-compressed file needn't to use such a flag, for we just change the
>     data write order of this format.

I don't understand.

First, let's stop using the "fixed" description.  It is definitely *not* fixed, but 
rather it is still a bogus, incomplete, dumpfile, and the user should be made aware 
of that fact.  

For compressed kdumps, the disk_dump_header.status field currently uses these
three bits:

 #define DUMP_DH_COMPRESSED_ZLIB    0x1   /* page is compressed with zlib */
 #define DUMP_DH_COMPRESSED_LZO     0x2   /* page is compressed with lzo */
 #define DUMP_DH_COMPRESSED_SNAPPY  0x4   /* page is compressed with snappy */
 
Can you please simply add a DUMP_DH_COMPRESSED_INCOMPLETE flag?

With respect to ELF vmcores, the processor-specific e_flags field is unused by the
crash utility, and it appears that makedumpfile always sets it to zero.  But
I'm not sure what the kernel does when /proc/vmcore is created?  Could there
be e_flags bits set there that a direct-copy of /proc/vmcore might contain?
That's why I suggested a unique ELF note.  

Then, if the flag is set, the crash utility can display "[INCOMPLETE]" next
to the dumpfile file name in the initial system banner and by the "sys" command.

And in the highly-likely event where the vmcore fails to initialize -- in that
case "crash -d1" can display the header contents immediately during invocation.  
That way, instead of users complaining about the crash utility, the blame can be
placed where it belongs.

> 2. We can just let makedumpfile change the "fixed" dumpfile's filename automatically.
>     Such as add a "-truncated" flag after those dumpfiles.

You probably should do that -- in *addition* to setting a flag in the header.  
Since there's no way to prevent a user from re-naming the file, without a flag,
there would be no way of confirming that it was a bogus dumpfile to begin with.

Thanks,
  Dave