From: Laszlo Ersek <lersek@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
Dave Anderson <anderson@redhat.com>, QEMU <qemu-devel@nongnu.org>,
Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 4/7] dump: add vmcoreinfo ELF note
Date: Thu, 6 Jul 2017 12:29:22 +0200 [thread overview]
Message-ID: <f2f82e05-f9af-ed63-b5cc-37307f48cd95@redhat.com> (raw)
In-Reply-To: <CAJ+F1CLgvHO3cm6+KM6RVG5AghronCq0KTG6GbEkLRa5Lo9m1A@mail.gmail.com>
On 07/05/17 23:52, Marc-André Lureau wrote:
> Hi
>
> On Wed, Jul 5, 2017 at 1:48 AM, Laszlo Ersek <lersek@redhat.com> wrote:
>> On 06/29/17 15:23, Marc-André Lureau wrote:
>>> @@ -258,6 +280,8 @@ static void write_elf64_notes(WriteCoreDumpFunction f, DumpState *s,
>>> return;
>>> }
>>> }
>>> +
>>> + write_vmcoreinfo_note(f, s, errp);
>>> }
>>>
>>> static void write_elf32_note(DumpState *s, Error **errp)
>>> @@ -303,6 +327,8 @@ static void write_elf32_notes(WriteCoreDumpFunction f, DumpState *s,
>>> return;
>>> }
>>> }
>>> +
>>> + write_vmcoreinfo_note(f, s, errp);
>>> }
>>>
>>
>> Wait, I'm confused again. You explained why it was OK to hook this logic
>> into the kdump handling too, but I don't think I understand your
>> explanation, so let me repeat my confusion below :)
>>
>> In the ELF case, this code works fine, I think. As long as the guest
>> provided us with a well-formed note, a well-formed note will be appended
>> to the ELF dump.
>>
>> But, this code is also invoked in the kdump case, and I don't understand
>> why that's a good thing. If I understand the next patch correctly, the
>> kdump format already provides crash with a (trimmed) copy of the guest
>> kernels vmcoreinfo note. So in the kdump case, why do we have to create
>> yet another copy of the guest kernel's vmcoreinfo note?
>>
>> Thus, my confusion persists, and I can only think (again) that
>> write_vmcoreinfo_note() should be called from dump_begin() only (at the
>> end). (And the s->note_size adjustment should take that into account.)
>>
>> Alternatively, we should keep this logic, and drop patch #5.
>
> You are right, sorry for my misunderstanding, although crash is seems
> fine as long as size/offsets are ok.
>
> So, instead of duplicating the info, let's keep the complete ELF note
> (with the header) in the dump, and simply adjust kdump header to point
> to the adjusted offset/size. This has the advantage of not making the
> code unnecessarily more complicated wrt s->note_size handling etc, and
> is consistent with the rest of the elf notes.
I guess that's OK, although I don't really see why even that is
necessary. The vmcoreinfo note should be possible to find in the kdump
output with the rest of the ELF notes, even without pointing some kdump
header fields into that specific note.
Snipping the rest because I'm going to see updates on those things in v2
anyway (which you've just posted).
Thanks
Laszlo
next prev parent reply other threads:[~2017-07-06 10:29 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-29 13:23 [Qemu-devel] [PATCH 0/7] KASLR kernel dump support Marc-André Lureau
2017-06-29 13:23 ` [Qemu-devel] [PATCH 1/7] vmgenid: replace x-write-pointer-available hack Marc-André Lureau
2017-06-29 14:11 ` Michael S. Tsirkin
2017-07-02 3:09 ` Ben Warren
2017-07-03 14:48 ` Eduardo Habkost
2017-07-03 18:06 ` Laszlo Ersek
2017-07-03 18:27 ` Eduardo Habkost
2017-07-03 18:35 ` Laszlo Ersek
2017-07-03 18:21 ` Michael S. Tsirkin
2017-07-03 18:38 ` Michael S. Tsirkin
2017-07-03 18:50 ` Eduardo Habkost
2017-07-03 19:51 ` Michael S. Tsirkin
2017-06-29 13:23 ` [Qemu-devel] [PATCH 2/7] acpi: add vmcoreinfo device Marc-André Lureau
2017-07-04 22:07 ` Laszlo Ersek
2017-07-05 13:54 ` Marc-André Lureau
2017-06-29 13:23 ` [Qemu-devel] [PATCH 3/7] tests: add simple vmcoreinfo test Marc-André Lureau
2017-06-29 13:23 ` [Qemu-devel] [PATCH 4/7] dump: add vmcoreinfo ELF note Marc-André Lureau
2017-07-04 23:48 ` Laszlo Ersek
2017-07-05 21:52 ` Marc-André Lureau
2017-07-06 10:29 ` Laszlo Ersek [this message]
2017-06-29 13:23 ` [Qemu-devel] [PATCH 5/7] kdump: " Marc-André Lureau
2017-07-05 0:07 ` Laszlo Ersek
2017-07-06 10:05 ` Marc-André Lureau
2017-06-29 13:23 ` [Qemu-devel] [PATCH 6/7] scripts/dump-guest-memory.py: add vmcoreinfo Marc-André Lureau
2017-07-05 0:22 ` Laszlo Ersek
2017-07-05 9:58 ` Marc-André Lureau
2017-07-05 11:05 ` Laszlo Ersek
2017-06-29 13:23 ` [Qemu-devel] [PATCH 7/7] MAINTAINERS: add Dump maintainers Marc-André Lureau
2017-07-05 0:26 ` Laszlo Ersek
2017-07-06 9:54 ` Marc-André Lureau
2017-07-06 10:17 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f2f82e05-f9af-ed63-b5cc-37307f48cd95@redhat.com \
--to=lersek@redhat.com \
--cc=anderson@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=marcandre.lureau@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).