[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v3 2/2] xen/vm-events: Move parts of monitor_domctl code to common-side.
- To: Jan Beulich <JBeulich@xxxxxxxx>
- From: Corneliu ZUZU <czuzu@xxxxxxxxxxxxxxx>
- Date: Mon, 15 Feb 2016 15:29:23 +0200
- Cc: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, Ian Campbell <ian.campbell@xxxxxxxxxx>, Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxx, Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
- Comment: DomainKeys? See http://domainkeys.sourceforge.net/
- Delivery-date: Mon, 15 Feb 2016 13:29:38 +0000
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=qgIqG6cvFmYyPc8K5bo9GTU50oCBrJsGaFZ+cma0RzS+PBu+zXInXZssSEJnBJpF4UHl4DfrfQNAegxyVd31fbbKKaoRNMsyi+3v+AjD/ESo0BFndkuo0d7S2AvbkpryWc6Ib90NIVEnFMIyjMCfvRs4k/teZ6CQPCqWv20f0c+TIWXoBkF9/NNCt3ib5fPYfsKATIKpaguG+XFinCgfVkcuBa2qhsoQ3w8ibgHslgL8pN2vpur+E80F2vw6dWfNE3zNA8x9qbJsyI6LT3Ang6d9f1bNIjU4dBqRAnhKsfJXqgJoS2W7+srhtHhkT1OMTJwbXJjfmoc/XBl1EESGJA==; h=Received:Received:Received:Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
|
On 2/15/2016 2:44 PM, Jan Beulich
wrote:
switch ( mop->op )
{
case XEN_DOMCTL_MONITOR_OP_ENABLE:
case XEN_DOMCTL_MONITOR_OP_DISABLE:
/* Check if event type is available. */
if ( unlikely(!(arch_monitor_get_capabilities(d) & (1 << mop->event))) )
return -EOPNOTSUPP;
/* Arch-side handles enable/disable ops. */
return arch_monitor_domctl_event(d, mop);
Ah, I see now that I've mis-read the default: code further below,
which actually calls arch_monitor_domctl_op(), not ..._event().
However, there's an "undefined behavior" issue with the code
above then when mop->event >= 31 - I think you want to left
shift 1U instead of plain 1, and you need to range check
mop->event first.
Jan
Never looked @ that part before, used it the way it was.
I suppose that's because "according to the C specification,
the result of a bit shift
operation on a signed argument gives implementation-defined
results, so in theory 1U << i is
more portable than 1 << i"
(taken from a stackoverflow post).
After changing 1 to 1U though, I don't understand why we should also
range-check mop->event.
I'm imagining when (mop->event > 31):
* (1U << mop->event) = 0 or >= (0x1 + 0xFFFFFFFF) (?)
* in both cases arch_monitor_get_capabilities(d) & (1U <<
mop->event) would be = 0
* in which case we would return -EOPNOTSUPP
, no?
Corneliu.
|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
