Re: [Crash-utility] Unknown osrelease information in vmcore with xen

----- Original Message ----- > > > ----- Original Message ----- > > > > > > ----- Original Message ----- > > > Hi, > > > > > > I have a SuSE SLES11 vmcore with xen and tried to read the osrelease from > > > the vmcore with > > > # crash --osrelease vmcore > > > unknown > > > > > > The problem is that there are two notes in the vmcore starting with > > > "VMCOREINFO": > > > > > > Elf64_Nhdr: > > > n_namesz: 11 ("VMCOREINFO") > > > n_descsz: 1384 > > > n_type: 0 (unused) > > > OSRELEASE=3.0.101-63-xen > > > ... > > > Elf64_Nhdr: > > > n_namesz: 15 ("VMCOREINFO_XEN") > > > n_descsz: 4068 > > > n_type: 0 (unused) > > > ... > > > > > > In the function dump_Elf64_Nhdr() I found: > > > vmcoreinfo = STRNEQ(buf, "VMCOREINFO"); > > > > > > But because the "VMCOREINFO_XEN" ist the second one in the file it wins! > > > > > > When using > > > vmcoreinfo = STREQ(buf, "VMCOREINFO"); > > > all is fine and I get: > > > # crash --osrelease vmcore > > > 3.0.101-63-xen > > > > > > So my question is: why is STRNEQ() used? > > > Thanks! > > > > Hello Dietmar, > > > > As I recall, I did all of the note name checks that way because the length > > of the name string is specified by the note->n_namesz field, and therefore > > not necessarily guaranteed to be a NULL-terminated string? In reality, > > they're probably will be a NULL there though. > > > > Anyway, I wasn't even familiar with the existence of a VMCOREINFO_XEN note, > > so please feel free to post a patch to address it. > > > > Dave > > > This should work, right?: > > --- crash-7.1.3/netdump.c.orig > +++ crash-7.1.3/netdump.c > @@ -1940,7 +1940,8 @@ dump_Elf32_Nhdr(Elf32_Off offset, int st > #endif > default: > xen_core = STRNEQ(buf, "XEN CORE") || STRNEQ(buf, "Xen"); > - vmcoreinfo = STRNEQ(buf, "VMCOREINFO"); > + if (!STRNEQ(buf, "VMCOREINFO_XEN")) > + vmcoreinfo = STRNEQ(buf, "VMCOREINFO"); > eraseinfo = STRNEQ(buf, "ERASEINFO"); > qemuinfo = STRNEQ(buf, "QEMU"); > if (xen_core) { > @@ -2196,7 +2197,8 @@ dump_Elf64_Nhdr(Elf64_Off offset, int st > #endif > default: > xen_core = STRNEQ(buf, "XEN CORE") || STRNEQ(buf, "Xen"); > - vmcoreinfo = STRNEQ(buf, "VMCOREINFO"); > + if (!STRNEQ(buf, "VMCOREINFO_XEN")) > + vmcoreinfo = STRNEQ(buf, "VMCOREINFO"); > eraseinfo = STRNEQ(buf, "ERASEINFO"); > qemuinfo = STRNEQ(buf, "QEMU"); > if (xen_core) { > > Dave Actually, the patch above will prevent the VMCOREINFO_XEN strings from being dumped in readable strings by "help -[nD]" or by "crash -d#". Try the attached patch instead, where both VMCOREINFO and VMCOREINFO_XEN string data will be dumped appropriately. I do have a couple old RHEL5 xen dom0 dumpfiles that have VMCOREINFO_XEN notes, but they do not have VMCOREINFO notes. It must be relatively newer Xen kernels that have both? Anyway, check out the updated patch and let me know.

And BTW, checking the ELF specs, the name string should be NULL-terminated, and the n_namesz count should include the NULL-byte: namesz and name The first namesz bytes in name contain a null-terminated character representation of the entry's owner and originator. There's an accompanying diagram example that shows the namesz value counting the NULL terminator. However, the reason for STRNEQ() in crash stems from the fact that the original "netdump" generated ELF vmcores were incorrectly created such the n_namesz count did not include the NULL, and I believe that the descriptor data started immediately after the name string.

For example, here's an old 2.6.9-based netdump generated vmcore, where the name is "CORE", and therefore *should* have a n_namesz of 5 if it included a NULL terminator: Elf64_Nhdr: n_namesz: 4 ("CORE") n_descsz: 336 n_type: 1 (NT_PRSTATUS) The correct way would include the NULL-byte as well, as is done with kdump generated ELF vmcores: Elf64_Nhdr: n_namesz: 5 ("CORE") n_descsz: 336 n_type: 1 (NT_PRSTATUS) So for backwards-compatibility, I'd prefer to leave the checks using STRNEQ().

Thanks, Dave