[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.