Re: [patch] pm_qos update fixing mmotm 2010-05-11 -dies inpm_qos_update_request()

From: mgross
Date: Sun May 16 2010 - 20:12:49 EST


On Mon, May 17, 2010 at 12:21:25AM +0200, Rafael J. Wysocki wrote:
> On Saturday 15 May 2010, mgross wrote:
> > On Sat, May 15, 2010 at 09:38:47PM +0200, Rafael J. Wysocki wrote:
> > > On Saturday 15 May 2010, mgross wrote:
> > > > I apologize for the goofy email address.
> > > >
> > > > The following is a fix for the crash reported by Valdis.
> > > >
> > > > The problem was that the original pm_qos silently fails when a request
> > > > update is passed to a parameter that has not been added to the list
> > > > yet. It seems that the e1000e is doing this. This update restores this
> > > > behavior.
> > > >
> > > > I need to think about how to better handle such abuse, but for now this
> > > > restores the original behavior.
> > >
> > > Can you please post a signed-off incremental patch against
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6.git for-llinus
> > >
> > > that contains your original PM QOS update?
> >
> > No problem:
> >
> > Signed-off-by: markgross <markgross@xxxxxxxxxxx>
>
> Thanks! Do you want to use this address for the sign-off or the Intel one?

I guess so. Ever since switching groups within intel last summer my
mgross@xxxxxxxxxxxxxxx address isn't checked as often as this one.

The other option is to use my outlook email (mark.gross@xxxxxxxxx), but
I really hate posting from outlook. Besides, doing upstream kernel
stuff isn't my day job any more so using markgross@xxxxxxxxxxx makes
sense to me.

thanks,

--mgross



>
> Rafael
>
>
> > From 487b8dcaeb66d3c226d4c06c1bd99689f93024be Mon Sep 17 00:00:00 2001
> > From: mgross <mgross@mgross-desktop.(none)>
> > Date: Sat, 15 May 2010 14:30:15 -0700
> > Subject: [PATCH] Gard against pm_qos users calling API before registering a proper
> > request.
> >
> > This update handles a use case where pm_qos update requests need to
> > silently fail if the update is being sent to a handle that is null.
> >
> > The problem was that the original pm_qos silently fails when a request
> > update is passed to a parameter that has not been added to the list yet.
> > This update restores that behavior.
> >
> > Signed-off-by: markgross <markgross@xxxxxxxxxxx>
> >
> > ---
> > kernel/pm_qos_params.c | 26 ++++++++++++++------------
> > 1 files changed, 14 insertions(+), 12 deletions(-)
> >
> > diff --git a/kernel/pm_qos_params.c b/kernel/pm_qos_params.c
> > index a1aea04..f42d3f7 100644
> > --- a/kernel/pm_qos_params.c
> > +++ b/kernel/pm_qos_params.c
> > @@ -252,19 +252,21 @@ void pm_qos_update_request(struct pm_qos_request_list *pm_qos_req,
> > int pending_update = 0;
> > s32 temp;
> >
> > - spin_lock_irqsave(&pm_qos_lock, flags);
> > - if (new_value == PM_QOS_DEFAULT_VALUE)
> > - temp = pm_qos_array[pm_qos_req->pm_qos_class]->default_value;
> > - else
> > - temp = new_value;
> > -
> > - if (temp != pm_qos_req->value) {
> > - pending_update = 1;
> > - pm_qos_req->value = temp;
> > + if (pm_qos_req) { /*guard against callers passing in null */
> > + spin_lock_irqsave(&pm_qos_lock, flags);
> > + if (new_value == PM_QOS_DEFAULT_VALUE)
> > + temp = pm_qos_array[pm_qos_req->pm_qos_class]->default_value;
> > + else
> > + temp = new_value;
> > +
> > + if (temp != pm_qos_req->value) {
> > + pending_update = 1;
> > + pm_qos_req->value = temp;
> > + }
> > + spin_unlock_irqrestore(&pm_qos_lock, flags);
> > + if (pending_update)
> > + update_target(pm_qos_req->pm_qos_class);
> > }
> > - spin_unlock_irqrestore(&pm_qos_lock, flags);
> > - if (pending_update)
> > - update_target(pm_qos_req->pm_qos_class);
> > }
> > EXPORT_SYMBOL_GPL(pm_qos_update_request);
> >
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/