From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>, TimDeegan <tim@xen.org>,
Ian Campbell <Ian.Campbell@eu.citrix.com>,
xen-devel <xen-devel@lists.xenproject.org>,
Keir Fraser <keir@xen.org>
Subject: Re: [PATCH v2] x86/HVM: avoid pointer wraparound in bufioreq handling
Date: Wed, 22 Jul 2015 16:45:24 +0100 [thread overview]
Message-ID: <alpine.DEB.2.02.1507221638550.17378@kaball.uk.xensource.com> (raw)
In-Reply-To: <55AFD1230200007800094251@prv-mh.provo.novell.com>
On Wed, 22 Jul 2015, Jan Beulich wrote:
> >>> On 22.07.15 at 16:49, <stefano.stabellini@eu.citrix.com> wrote:
> > On Wed, 22 Jul 2015, Jan Beulich wrote:
> >> >>> On 21.07.15 at 18:18, <stefano.stabellini@eu.citrix.com> wrote:
> >> > On Thu, 18 Jun 2015, Jan Beulich wrote:
> >> >> --- a/xen/arch/x86/hvm/hvm.c
> >> >> +++ b/xen/arch/x86/hvm/hvm.c
> >> >> @@ -921,7 +921,7 @@ static void hvm_ioreq_server_disable(str
> >> >>
> >> >> static int hvm_ioreq_server_init(struct hvm_ioreq_server *s, struct domain *d,
> >> >> domid_t domid, bool_t is_default,
> >> >> - bool_t handle_bufioreq, ioservid_t id)
> >> >> + int bufioreq_handling, ioservid_t id)
> >> >
> >> > uint8_t?
> >>
> >> Why? I'm generally against using fixed width types when you don't
> >> really need them. And using uint_least8_t or uint_fast8_t is neither
> >> an opton, nor would it make the code look reasonable. Plain int is
> >> just fine here.
> >
> > You are not just changing integer size but also switching from unsigned
> > to signed implicitly. I think it is not a good coding practice.
>
> To me bool (and by implication bool_t) is neither a signed nor
> an unsigned type.
I meant that handle_bufioreq, a uint8_t, is actually transparently
passed to hvm_create_ioreq_server, that takes an int as argument.
I think it should be avoided, or casted explicitly to avoid confusion
in the future.
prev parent reply other threads:[~2015-07-22 15:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 13:14 [PATCH v2] x86/HVM: avoid pointer wraparound in bufioreq handling Jan Beulich
2015-06-18 13:41 ` Andrew Cooper
2015-07-21 16:18 ` Stefano Stabellini
2015-07-22 13:38 ` Jan Beulich
2015-07-22 14:49 ` Stefano Stabellini
2015-07-22 15:21 ` Jan Beulich
2015-07-22 15:45 ` Stefano Stabellini [this message]
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=alpine.DEB.2.02.1507221638550.17378@kaball.uk.xensource.com \
--to=stefano.stabellini@eu.citrix.com \
--cc=Ian.Campbell@eu.citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=keir@xen.org \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.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.