All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Andres Lagar Cavilla <andres@lagarcavilla.org>
Cc: Aravindh Puthiyaparambil <aravindp@cisco.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH v3 2/2] Xen/mem_event: Prevent underflow of vcpu pause counts
Date: Fri, 18 Jul 2014 17:44:40 +0100	[thread overview]
Message-ID: <53C94EF8.3010504@citrix.com> (raw)
In-Reply-To: <CADzFZPt7xM=5-jXNtZNuejTroUt5B6jtk=Rn9=5gR5RrXULsCQ@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 3328 bytes --]

On 18/07/14 17:37, Andres Lagar Cavilla wrote:
> On Fri, Jul 18, 2014 at 9:53 AM, Andrew Cooper
> <andrew.cooper3@citrix.com <mailto:andrew.cooper3@citrix.com>> wrote:
>
>     Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com
>     <mailto:andrew.cooper3@citrix.com>>
>     Tested-by: Razvan Cojocaru <rcojocaru@bitdefender.com
>     <mailto:rcojocaru@bitdefender.com>>
>     CC: Jan Beulich <JBeulich@suse.com <mailto:JBeulich@suse.com>>
>     CC: Tim Deegan <tim@xen.org <mailto:tim@xen.org>>
>     CC: Andres Lagar-Cavilla <andres@lagarcavilla.org
>     <mailto:andres@lagarcavilla.org>>
>     CC: Aravindh Puthiyaparambil <aravindp@cisco.com
>     <mailto:aravindp@cisco.com>>
>
> Reviewed-by: Andres Lagar-Cavilla <andres@lagarcavilla.org
> <mailto:andres@lagarcavilla.org>>
>
> Couple nits below ...
>
>
>     --
>     v3:
>      * Newline on warning
>     v2:
>      * Allow for multiple pause refcounts
>     ---
>      xen/arch/x86/hvm/hvm.c          |    2 +-
>      xen/arch/x86/mm/mem_event.c     |   31
>     +++++++++++++++++++++++++++++++
>      xen/arch/x86/mm/mem_sharing.c   |    4 ++--
>      xen/arch/x86/mm/p2m.c           |    8 ++++----
>      xen/include/asm-x86/mem_event.h |    3 +++
>      xen/include/xen/sched.h         |    3 +++
>      6 files changed, 44 insertions(+), 7 deletions(-)
>
>     diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>     index ef2411c..efd79b8 100644
>     --- a/xen/arch/x86/hvm/hvm.c
>     +++ b/xen/arch/x86/hvm/hvm.c
>     @@ -6113,7 +6113,7 @@ static int hvm_memory_event_traps(long p,
>     uint32_t reason,
>          if ( (p & HVMPME_MODE_MASK) == HVMPME_mode_sync )
>          {
>              req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
>     -        vcpu_pause_nosync(v);
>     +        mem_event_vcpu_pause(v);
>          }
>
>          req.gfn = value;
>     diff --git a/xen/arch/x86/mm/mem_event.c b/xen/arch/x86/mm/mem_event.c
>     index 40ae841..ba7e71e 100644
>     --- a/xen/arch/x86/mm/mem_event.c
>     +++ b/xen/arch/x86/mm/mem_event.c
>     @@ -663,6 +663,37 @@ int mem_event_domctl(struct domain *d,
>     xen_domctl_mem_event_op_t *mec,
>          return rc;
>      }
>
>     +void mem_event_vcpu_pause(struct vcpu *v)
>     +{
>     +    ASSERT(v == current);
>     +
>     +    atomic_inc(&v->mem_event_pause_count);
>
> Nit #1: A buggy toolstack going into an infinite loop could overflow
> this.

No it can't (or rather, I am fairly certain it can't).  This is
unconditionally in the context of a running vcpu, given the assertion
above.  This cannot increment the refcount more than number of
mem_events triggered from a single exit into Xen.

>     +    vcpu_pause_nosync(v);
>     +}
>     +
>     +void mem_event_vcpu_unpause(struct vcpu *v)
>     +{
>     +    int old, new, prev = v->mem_event_pause_count.counter;
>
> Nit #2: not fresh in my mind whether atomic is supposed to be signed
> or unsigned. The flawless comparison below is to take these all as
> unsigned and check for new > old.
>
> Thanks
> Andres

The inards of an atomic_t is signed.

Ideally I would make use of atomic_dec_bounded() from an early version
of my pausedomain patch, but Jan requested that I drop that part for
easier backport, given only a single consumer.

Given new consumers, that decision might be up for reconsideration.

~Andrew

[-- Attachment #1.2: Type: text/html, Size: 6846 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2014-07-18 16:44 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-17 13:10 [PATCH 0/2] Xen/mem_event: Do not rely on the toolstack being bug-free Andrew Cooper
2014-07-17 13:10 ` [PATCH 1/2] Xen/mem_event: Validate the response vcpu_id before acting on it Andrew Cooper
2014-07-17 18:33   ` Andres Lagar Cavilla
2014-07-17 13:10 ` [PATCH 2/2] Xen/mem_event: Prevent underflow of vcpu pause counts Andrew Cooper
2014-07-17 18:38   ` Andres Lagar Cavilla
     [not found]     ` <CAGU+auv8zMj+xqU8KhbQSZXM+J+HovjV=TZMab5Z+nzNCvpjaQ@mail.gmail.com>
2014-07-17 18:51       ` Aravindh Puthiyaparambil (aravindp)
2014-07-17 18:54         ` Andres Lagar Cavilla
2014-07-17 18:57           ` Aravindh Puthiyaparambil (aravindp)
2014-07-17 19:07           ` Andrew Cooper
2014-07-17 19:18             ` Aravindh Puthiyaparambil (aravindp)
2014-07-17 18:55     ` Andrew Cooper
2014-07-18  9:42     ` Ian Campbell
2014-07-18 10:41   ` [PATCH v2 " Andrew Cooper
2014-07-18 13:47     ` Razvan Cojocaru
2014-07-18 13:53     ` [PATCH v3 " Andrew Cooper
2014-07-18 16:37       ` Andres Lagar Cavilla
2014-07-18 16:44         ` Andrew Cooper [this message]
2014-07-18 17:29       ` Aravindh Puthiyaparambil (aravindp)
2014-07-17 13:23 ` [PATCH 0/2] Xen/mem_event: Do not rely on the toolstack being bug-free Tim Deegan
2014-07-17 14:40 ` Razvan Cojocaru
2014-07-17 14:46   ` Andrew Cooper
2014-07-17 14:50     ` Razvan Cojocaru
     [not found] ` <CAGU+auuzOr5HSErrxmyhtxtP74gn=0L5TAZGR8FWBF6MeGFxUA@mail.gmail.com>
2014-07-17 19:01   ` Aravindh Puthiyaparambil (aravindp)
2014-07-17 20:26     ` Razvan Cojocaru
2014-07-17 22:17       ` Tamas Lengyel
2014-07-17 22:42         ` 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=53C94EF8.3010504@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andres@lagarcavilla.org \
    --cc=aravindp@cisco.com \
    --cc=tim@xen.org \
    --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.