public inbox for kexec@lists.infradead.org
 help / color / mirror / Atom feed
From: Petr Tesarik <ptesarik@suse.cz>
To: kexec@lists.infradead.org
Cc: Norbert Trapp <Norbert.Trapp@ts.fujitsu.com>
Subject: [PATCHv3 2/9] Xen: Fix the offset of the _domain field in struct page_info
Date: Fri, 24 Aug 2012 17:41:55 +0200	[thread overview]
Message-ID: <201208241741.55847.ptesarik@suse.cz> (raw)

The page_info structure was re-arranged in Xen-3.4 (with changeset
162cdb596b9a), and the _domain field moved from union "u" to union "v"
on x86 and x86_64.

By using OFFSET_IN_UNION_INIT we can cover all cases:

1. old placement in union "u"
2. new placement in union "v" on x86 and x86_64
3. unmodified placement in union "u" on ia64

Unfortunately, the re-arrangement was not reflected in xen/common/kexec.c,
so the page_info _domain offset was still set with:
    VMCOREINFO_OFFSET_ALIAS(page_info, u, _domain);

The bug was spotted during Xen-4.1 development (changeset cb756381087c),
and all Xen-4.1 releases are fixed like this:
    #ifdef __ia64__
	VMCOREINFO_OFFSET_SUB(page_info, u.inuse, _domain);
    #else
	VMCOREINFO_OFFSET_SUB(page_info, v.inuse, _domain);
    #endif

This changeset was also backported to Xen-4.0 branch as changeset
3b90a5353f20, which first went into Xen-4.0.2.
For Xen-3.4, this bug was never fixed.

To sum it up:
1. Xen versions up to and including Xen-3.3 output the correct offset
2. Xen-4.1 and above is also correct
3. Xen-4.0 is broken up to 4.0.2
4. Xen-3.4 is always broken

Some OS vendors may also have backported the patch to an otherwise broken
version, so the above summary may not be reliable.

Anyway, the VMCOREINFO produced by some Xen versions is wrong, and
makedumpfile will behave incorrectly. Adding a workaround to makedumpfile
for a bug in another package is wrong, because:

A. Self-reliant users should upgrade Xen.
B. Users of distro packages should report it as a bug to their vendor, and
   the vendor should backport the patch.
C. Users who need an immediate workaround should generate a vmcoreinfo file
   using makedumpfile, which will be correct after applying this patch.

Signed-off-by: Norbert Trapp <norbert.trapp@ts.fujitsu.com>
Signed-off-by: Petr Tesarik <ptesarik@suse.cz>

---
 makedumpfile.c |    5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -5306,10 +5306,7 @@ get_structure_info_xen(void)
 {
 	SIZE_INIT(page_info, "page_info");
 	OFFSET_INIT(page_info.count_info, "page_info", "count_info");
-	/*
-	 * _domain is the first member of union u
-	 */
-	OFFSET_INIT(page_info._domain, "page_info", "u");
+	OFFSET_IN_UNION_INIT(page_info._domain, "page_info", "_domain");
 
 	SIZE_INIT(domain, "domain");
 	OFFSET_INIT(domain.domain_id, "domain", "domain_id");



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

                 reply	other threads:[~2012-08-24 15:42 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=201208241741.55847.ptesarik@suse.cz \
    --to=ptesarik@suse.cz \
    --cc=Norbert.Trapp@ts.fujitsu.com \
    --cc=kexec@lists.infradead.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