From: Dario Faggioli <dario.faggioli@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com>,
Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH] tools/libxl: Don't read off the end of tinfo[]
Date: Tue, 18 Feb 2014 17:33:37 +0100 [thread overview]
Message-ID: <1392741217.32038.563.camel@Solace> (raw)
In-Reply-To: <1392739145-24664-1-git-send-email-andrew.cooper3@citrix.com>
[-- Attachment #1.1: Type: text/plain, Size: 2177 bytes --]
On mar, 2014-02-18 at 15:59 +0000, Andrew Cooper wrote:
> It is very common for BIOSes to advertise more cpus than are actually present
> on the system, and mark some of them as offline. This is what Xen does to
> allow for later CPU hotplug, and what BIOSes common to multiple different
> systems do to to save fully rewriting the MADT in memory.
>
> An excerpt from `xl info` might look like:
>
> ...
> nr_cpus : 2
> max_cpu_id : 3
> ...
>
> Which shows 4 CPUs in the MADT, but only 2 online (as this particular box is
> the dual-core rather than the quad-core SKU of its particular brand)
>
> Because of the way Xen exposes this information, a libxl_cputopology array is
> bounded by 'nr_cpus', while cpu bitmaps are bounded by 'max_cpu_id + 1'.
>
> The current libxl code has two places which erroneously assume that a
> libxl_cputopology array is as long as the number of bits found in a cpu
> bitmap, and valgrind complains:
>
> ==14961== Invalid read of size 4
> ==14961== at 0x407AB7F: libxl__get_numa_candidate (libxl_numa.c:230)
> ==14961== by 0x407030B: libxl__build_pre (libxl_dom.c:167)
> ==14961== by 0x406246F: libxl__domain_build (libxl_create.c:371)
> ...
> ==14961== Address 0x4324788 is 8 bytes after a block of size 24 alloc'd
> ==14961== at 0x402669D: calloc (in/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
> ==14961== by 0x4075BB9: libxl__zalloc (libxl_internal.c:83)
> ==14961== by 0x4052F87: libxl_get_cpu_topology (libxl.c:4408)
> ==14961== by 0x407A899: libxl__get_numa_candidate (libxl_numa.c:342)
> ...
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Ian Campbell <Ian.Campbell@citrix.com>
> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Dario Faggioli <dario.faggioli@citrix.com>
>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2014-02-18 16:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-18 15:59 [PATCH] tools/libxl: Don't read off the end of tinfo[] Andrew Cooper
2014-02-18 16:33 ` Dario Faggioli [this message]
2014-02-18 16:39 ` Ian Campbell
2014-02-18 18:14 ` Andrew Cooper
2014-03-11 13:43 ` Andrew Cooper
2014-03-12 14:54 ` Ian Campbell
2014-05-22 15:52 ` Ian Jackson
2014-05-22 15:53 ` Andrew Cooper
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=1392741217.32038.563.camel@Solace \
--to=dario.faggioli@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=xen-devel@lists.xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.