From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH] tools/libxc: Fix error checking for xc_get_{cpu, node}map_size() callers
Date: Thu, 12 Dec 2013 21:05:47 +0000 [thread overview]
Message-ID: <52AA252B.2070109@citrix.com> (raw)
In-Reply-To: <1386860178.5488.113.camel@Solace>
On 12/12/2013 14:56, Dario Faggioli wrote:
> On gio, 2013-12-12 at 14:24 +0000, Ian Campbell wrote:
>> On Wed, 2013-12-11 at 15:47 +0000, Andrew Cooper wrote:
>>> c/s 2e82c18cd850592ae9a1f682eb93965a868b5f2f changed the error returns of
>>> xc_get_{cpu,node}map_size() to now include returning -1. This invalidated the
>>> error checks from callers, which expected 0 to be the only error case.
>> I don't think 0 is a valid error value any more. Neither xc_get_max_cpus
>> nor xc_get_max_nodes can return 0 and the map_size functions will round
>> to 1 or more.
>>
> Yep, I confirm that, after that changeset, neither
> xc_get_max_{cpus,nodes}() nor xc_get_{cpu,node}map_size() return 0 as an
> error anymore.
Zero might not be "the error condition" any more, but it is certainly an
error from any of these functions (and possible as
xc_get_max_{cpus,nodes}() is capable of returning 0 if Xen hands back -1
for physinfo.max_{cpu,node}_id)
>
>> So these could all be "< 0" tests think.
>>
> Indeed.
>
> Anyway, looks like, while I fixed the callers of the xx_get_max_xx
> things in that very comment, I didn't do the same for the xx_get_*map_xx
> ones. Weird, as ISTR doing so too... :-/
>
> Anyway, thanks to Coverity for caching this and to Andrew for the patch.
>
> I'll reply to v2 (if you're posting it) but, with the conditions
> converted to "< 0", this can have my:
>
> Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
>
> Regards,
> Dario
>
xc_{cpu/node}map_alloc() must strictly still be "<= 0" checks to avoid
the issue where calloc(1, 0) returns a non-NULL pointer.
Currently, I am of the opinion that the patch is better as is, than
changing some of the checks to being strictly "< 0"
~Andrew
next prev parent reply other threads:[~2013-12-12 21:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-11 15:47 [PATCH] tools/libxc: Fix error checking for xc_get_{cpu, node}map_size() callers Andrew Cooper
2013-12-12 14:24 ` Ian Campbell
2013-12-12 14:56 ` Dario Faggioli
2013-12-12 21:05 ` Andrew Cooper [this message]
2013-12-12 23:59 ` Dario Faggioli
2013-12-13 0:35 ` Andrew Cooper
2013-12-13 10:13 ` Dario Faggioli
2013-12-18 11:10 ` Ian Campbell
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=52AA252B.2070109@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=dario.faggioli@citrix.com \
--cc=george.dunlap@eu.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.