From: Dario Faggioli <dario.faggioli@citrix.com>
To: Meng Xu <mengxu@cis.upenn.edu>
Cc: george.dunlap@eu.citrix.com,
"konrad.r.wilk" <konrad.r.wilk@gmail.com>,
xumengpanda@gmail.com, JBeulich@suse.com,
xen-devel@lists.xen.org
Subject: Re: [PATCH for Xen 4.5 v2 1/2] xen: sanity check input and serialization in sched_rt.c
Date: Wed, 29 Oct 2014 10:41:32 +0100 [thread overview]
Message-ID: <1414575692.20696.42.camel@Abyss> (raw)
In-Reply-To: <1414246599-3914-2-git-send-email-mengxu@cis.upenn.edu>
[-- Attachment #1.1: Type: text/plain, Size: 2421 bytes --]
[Ditto, about the Cc list]
On Sat, 2014-10-25 at 10:16 -0400, Meng Xu wrote:
> Sanity check input params in rt_dom_cntl();
> Serialize rt_dom_cntl() against the global lock.
>
> Signed-off-by: Meng Xu <mengxu@cis.upenn.edu>
>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Just a note. See below.
> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> index 6c8faeb..b87c95b 100644
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -1042,9 +1042,11 @@ rt_dom_cntl(
> struct domain *d,
> struct xen_domctl_scheduler_op *op)
> {
> + struct rt_private *prv = rt_priv(ops);
> struct rt_dom * const sdom = rt_dom(d);
> struct rt_vcpu *svc;
> struct list_head *iter;
> + unsigned long flags;
> int rc = 0;
>
> switch ( op->cmd )
> @@ -1055,12 +1057,19 @@ rt_dom_cntl(
> op->u.rtds.budget = svc->budget / MICROSECS(1);
> break;
> case XEN_DOMCTL_SCHEDOP_putinfo:
> + if ( op->u.rtds.period == 0 || op->u.rtds.budget == 0 )
> + {
> + rc = -EINVAL;
> + break;
> + }
> + spin_lock_irqsave(&prv->lock, flags);
> list_for_each( iter, &sdom->vcpu )
> {
> struct rt_vcpu * svc = list_entry(iter, struct rt_vcpu, sdom_elem);
> svc->period = MICROSECS(op->u.rtds.period); /* transfer to nanosec */
> svc->budget = MICROSECS(op->u.rtds.budget);
> }
> + spin_unlock_irqrestore(&prv->lock, flags);
>
Thinking more about this, I actually prefer the approach where both the
get and set side are properly serialized. Races are very unlikely, and
probably not that harmful, but I don't see why leaving room for them,
and it looks more consistent to me that way.
I appreciate why you've done it this way in this patch, and I am fine
with it. As said, it's not a huge deal, and this code is experimental,
so we can always change it later.
I just wanted to let you know that, if you end up resending the patches
for some reasons, I'd personally go for the fully locked approach.
Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2014-10-29 9:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-25 14:16 Sanity check input and serialize vcpu data in sched_rt.c Meng Xu
2014-10-25 14:16 ` [PATCH for Xen 4.5 v2 1/2] xen: sanity check input and serialization " Meng Xu
2014-10-29 9:41 ` Dario Faggioli [this message]
2014-10-29 14:27 ` Meng Xu
2014-11-10 12:54 ` George Dunlap
2014-10-25 14:16 ` [PATCH for Xen 4.5 v2 2/2] xen: serialize vcpu data " Meng Xu
2014-10-29 9:26 ` Dario Faggioli
2014-11-10 12:53 ` George Dunlap
2014-11-10 15:29 ` Meng Xu
2014-11-10 15:36 ` Dario Faggioli
2014-11-10 15:38 ` George Dunlap
2014-11-10 15:40 ` George Dunlap
2014-11-10 16:04 ` Meng Xu
2014-11-10 16:15 ` George Dunlap
2014-10-29 10:06 ` Sanity check input and " Dario Faggioli
2014-10-29 14:23 ` Meng Xu
2014-10-29 17:52 ` Konrad Rzeszutek Wilk
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=1414575692.20696.42.camel@Abyss \
--to=dario.faggioli@citrix.com \
--cc=JBeulich@suse.com \
--cc=george.dunlap@eu.citrix.com \
--cc=konrad.r.wilk@gmail.com \
--cc=mengxu@cis.upenn.edu \
--cc=xen-devel@lists.xen.org \
--cc=xumengpanda@gmail.com \
/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.