Re: [RFC] pm_qos: reimplement using plists

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 06 Jun 2010 23:05:06 -0400
James Bottomley <James.Bottomley@xxxxxxx> wrote:

> On Sun, 2010-06-06 at 14:39 -0700, mark gross wrote:
> > > @@ -251,22 +244,27 @@ void pm_qos_update_request(struct pm_qos_request_list *pm_qos_req,
> > >  	unsigned long flags;
> > >  	int pending_update = 0;
> > >  	s32 temp;
> > > +	struct pm_qos_object *o;
> > >  
> > > -	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 (!pm_qos_req) /*guard against callers passing in null */
> > > +		return;
> > 
> > need a better test to see if the pm_qos_req is in the plist or not as we
> > move to a caller allocated design.
> 
> This is a guard against callers passing in NULL ... which is probably
> unnecessary ... I think oopsing on a NULL deref would be just fine for
> that, since it would represent a programming error.

That is bad in the general case because you then depend on
mmap_min_addr to be sufficiently large.

I would advocate for not making the attack surface that big.

Cheers,
Flo
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux