From: Mark Gross <mgross@linux.intel.com>
To: Paul Mundt <lethal@linux-sh.org>,
linux-pm <linux-pm@lists.linux-foundation.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] QoS params patch
Date: Thu, 27 Sep 2007 09:21:09 -0700 [thread overview]
Message-ID: <20070927162109.GG25718@linux.intel.com> (raw)
In-Reply-To: <20070927022440.GB25873@linux-sh.org>
On Thu, Sep 27, 2007 at 11:24:40AM +0900, Paul Mundt wrote:
> On Wed, Sep 26, 2007 at 03:40:26PM -0700, Mark Gross wrote:
> > + struct list_head list;
> > + union {
> > + s32 value;
> > + s32 usec;
> > + s32 kbps;
> > + };
> > + char *name;
>
> Your } is in a strange place. It looks like it wants to join its friends
> closer to the left margin ;-)
fixed.
>
> > +};
> > +
> > +#define QOS_RESERVED 0
> > +#define QOS_CPU_DMA_LATENCY 1
> > +#define QOS_NETWORK_LATENCY 2
> > +#define QOS_NETWORK_THROUGHPUT 3
> > +
> > +#define QOS_NUM_CLASSES 4
> > +#define QOS_DEFAULT_VALUE -1
>
> an enum would be better for this, especially as people are likely to add
> new types, having to update QOS_NUM_CLASSES each time sucks.
I'm partial to the simplicity of not using an enum in this case. We do
want it to be somewhat non-trivial to add qos classes.
>
> > +/* static helper functions */
> > +static s32 max_compare(s32 v1, s32 v2)
> > +{
> > + if (v1 < v2)
> > + return v2;
> > + else
> > + return v1;
> > +}
> > +
> > +static s32 min_compare(s32 v1, s32 v2)
> > +{
> > + if (v1 < v2)
> > + return v1;
> > + else
> > + return v2;
> > +}
> > +
> min()/max() instead?
done.
>
> > +/* assumes qos_lock is held */
> > +static void update_target(int i)
> > +{
> 'target' might be a more meaningful variable name.
done.
>
> > + qos->qos_power_miscdev.fops = &qos_power_fops;
> > +
> > + ret = misc_register(& qos->qos_power_miscdev);
> > + if (ret < 0 )
> > + printk(KERN_ERR "qos_power: misc_register returns %d.\n", ret);
> > +
> > + return ret;
> > +}
> > +
> Just return misc_register(...); ?
ok.
>
> > + if( i < QOS_NUM_CLASSES) {
> > + qos = &qos_array[i];
> > + qos->name = kstrdup(name, GFP_KERNEL);
> > + if(!qos->name)
> > + goto cleanup;
> > +
> > + qos->default_value = default_value;
> > + qos->target_value = default_value;
> > + qos->comparitor = comparitor;
> > + srcu_init_notifier_head(&qos->notifiers);
> > + INIT_LIST_HEAD(&qos->requirements.list);
> > + if (register_new_qos_misc(qos) < 0 )
> > + goto cleanup;
> > + }
> > + return;
> > +cleanup:
> > + kfree(qos->name);
> > +}
>
> This leaks. You'll have to scan down from i and clean up the kstrdup()
> per qos_array element. Presently this will only free the first one to fail
> registration.
Not seeing the leak here. this is an if block not a for loop.
>
> > +
> > +int qos_add_requirement(int i, char *name, s32 value)
> > +{
> > + struct requirement_list * dep;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&qos_lock, flags);
> > + dep = kzalloc(sizeof(struct requirement_list), GFP_KERNEL);
>
> kmalloc() under a spinlock. GFP_KERNEL implies __GFP_WAIT, which can
> sleep. Slab debugging would have caught this, too.
>
/me turns on slab debugging.
> > + if (dep) {
> > + if (value == QOS_DEFAULT_VALUE)
> > + dep->value = qos_array[i].default_value;
> > + else
> > + dep->value = value;
> > + dep->name = kstrdup(name, GFP_KERNEL);
>
> And here also, still under the spinlock. You can probably rework the
> locking just to protect the list, if you really need it at all, it
> doesn't seem to matter anywhere else here.
>
Re-worked. I didn't need the lock to be held as long as I had it.
Thanks for catching this!
> > + if(!dep->name)
> > + goto cleanup;
> > +
> > + list_add(&dep->list, &qos_array[i].requirements.list);
> > + update_target(i);
> > + spin_unlock_irqrestore(&qos_lock, flags);
> > +
> > + return 0;
> > + }
> > + spin_unlock_irqrestore(&qos_lock, flags);
> > +
> > +cleanup:
> > + if(dep)
> > + kfree(dep);
>
> no if() needed.
fixed.
>
> > + return -ENOMEM;
> > +}
> > +EXPORT_SYMBOL_GPL(qos_add_requirement);
>
> You also didn't spin_unlock_irqrestore() in the error path, so this bails
> out with the lock held and IRQs disabled.
fixed by the re-work.
--mgross
next prev parent reply other threads:[~2007-09-27 16:21 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-26 22:37 [RFC] QoS power Management enabling patch set Mark Gross
2007-09-26 22:40 ` [RFC] QoS params patch Mark Gross
2007-09-26 22:40 ` Mark Gross
2007-09-26 23:41 ` Randy Dunlap
2007-09-27 0:40 ` Mark Gross
2007-09-27 0:40 ` Mark Gross
2007-09-27 2:53 ` Valdis.Kletnieks
2007-09-27 2:53 ` Valdis.Kletnieks
2007-09-27 3:18 ` Paul Mundt
2007-09-27 3:18 ` Paul Mundt
2007-09-27 15:17 ` Mark Gross
2007-09-27 15:17 ` Mark Gross
2007-09-27 15:36 ` Mark Gross
2007-09-27 15:36 ` Mark Gross
2007-09-27 13:00 ` roel
2007-09-27 13:00 ` roel
2007-09-26 23:41 ` Randy Dunlap
2007-09-27 2:24 ` Paul Mundt
2007-09-27 2:24 ` Paul Mundt
2007-09-27 4:05 ` Randy Dunlap
2007-09-27 15:37 ` Mark Gross
2007-09-27 15:37 ` Mark Gross
2007-09-27 20:17 ` [RFC] QoS params patch update Mark Gross
2007-09-28 0:08 ` Paul Mundt
2007-09-28 0:08 ` Paul Mundt
2007-09-27 20:17 ` Mark Gross
2007-09-27 4:05 ` [RFC] QoS params patch Randy Dunlap
2007-09-27 16:21 ` Mark Gross [this message]
2007-09-27 16:21 ` Mark Gross
2007-09-28 6:25 ` Andrew Morton
2007-09-28 6:25 ` Andrew Morton
2007-09-28 6:41 ` Paul Mundt
2007-09-28 6:41 ` Paul Mundt
2007-09-28 17:22 ` Mark Gross
2007-09-28 17:22 ` Mark Gross
2007-09-28 17:19 ` Mark Gross
2007-09-28 17:19 ` Mark Gross
2007-09-28 18:51 ` Andrew Morton
2007-10-01 16:11 ` Mark Gross
2007-10-01 16:11 ` Mark Gross
2007-09-28 18:51 ` Andrew Morton
2007-09-26 22:42 ` [RFC] QoS power Management enabling patch set Mark Gross
2007-09-26 22:42 ` Mark Gross
2007-09-26 22:45 ` [RFC] QoS power example / hack Mark Gross
2007-09-26 22:45 ` Mark Gross
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=20070927162109.GG25718@linux.intel.com \
--to=mgross@linux.intel.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.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.