Hi Dave,
Am Freitag 11 Dezember 2015, 14:35:56 schrieb Dave Anderson:
>
> ----- 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.
Thanks the patch works very well!
Only a minor nit, now the n_type has changed:
Elf64_Nhdr:
n_namesz: 15 ("VMCOREINFO_XEN")
n_descsz: 4068
n_type: 0 (?)
I'm not familiar enough what should be the right one:
"n_type: 0 (?)" or "n_type: 0 (unused)"
If the second this works for 64 bit:
--- a/netdump.c
+++ b/netdump.c
@@ -2231,6 +2231,8 @@ dump_Elf64_Nhdr(Elf64_Off offset, int store)
} else if (qemuinfo) {
pc->flags2 |= QEMU_MEM_DUMP_ELF;
netdump_print("(QEMUCPUState)\n");
+ } else if (vmcoreinfo_xen) {
+ netdump_print("(unused)\n");
} else
netdump_print("(?)\n");
break;
>
> 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.
OK, I understand.
>
> 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().
Yes you are right.
Many thanks!
Dietmar.
>
> Thanks,
> Dave
--
Company details: http://ts.fujitsu.com/imprint.html
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
