linux-kernel - RE: [PATCH] intel_menlo: max_state is unsigned, invalid test

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7D0189F5BE1DF549A570B212D1D5612182AEA5@bgsmsx412.gar.corp.intel.com>
Date:	Wed, 5 Nov 2008 15:50:37 +0530
From:	"Thomas, Sujith" <sujith.thomas@...el.com>
To:	"Len Brown" <lenb@...nel.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Zhang, Rui" <rui.zhang@...el.com>
Cc:	"roel kluin" <roel.kluin@...il.com>,
	"Brown, Len" <len.brown@...el.com>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	<linux-acpi@...r.kernel.org>
Subject: RE: [PATCH] intel_menlo: max_state is unsigned, invalid test



>-----Original Message-----
>From: Len Brown [mailto:lenb@...nel.org]
>Sent: Tuesday, November 04, 2008 9:37 AM
>To: Andrew Morton; Thomas, Sujith; Zhang, Rui
>Cc: roel kluin; Brown, Len; Linux Kernel Mailing List; linux-
>acpi@...r.kernel.org
>Subject: Re: [PATCH] intel_menlo: max_state is unsigned, invalid test
>
>
>
>On Mon, 3 Nov 2008, Andrew Morton wrote:
>
>> On Wed, 29 Oct 2008 17:06:47 -0400
>> roel kluin <roel.kluin@...il.com> wrote:
>>
>> > max_state is unsigned, so the test is invalid.
>> >
>> > Signed-off-by: Roel Kluin <roel.kluin@...il.com>
>> > ---
>> > I think max_state can only become -1, no? then probably a different
>> > patch is required.
>> > I may not be able to respond for a few weeks.
>> >
>> > diff --git a/drivers/misc/intel_menlow.c
b/drivers/misc/intel_menlow.c
>> > index e00a275..980171d 100644
>> > --- a/drivers/misc/intel_menlow.c
>> > +++ b/drivers/misc/intel_menlow.c
>> > @@ -121,7 +121,7 @@ static int memory_set_cur_bandwidth(struct
>thermal_cooling_device *cdev,
>> >  	if (memory_get_int_max_bandwidth(cdev, &max_state))
>> >  		return -EFAULT;
>> >
>> > -	if (max_state < 0 || state > max_state)
>> > +	if (max_state == -1 || state > max_state)
>> >  		return -EINVAL;
>> >
>> >  	arg_list.count = 1;
>> >
>>
>> hm, maybe.
>>
>> This can only happen if acpi_evaluate_integer(MEMORY_GET_BANDWIDTH)
>> returned no-error and a bandwidth of zero (I assume).
>>
>> Is this a special case which the driver really wanted to handle?  If
>> so, why is "0" the only bad value which we're checking for?  Or is
this
>> all some big brainfart which should be removed?
>
>Sujith,
>Please send me a patch to intel_menlo.c that documents the
>legal return values from GTHS.
>
>If 0 is illegal, that is fine, but the upstream driver doesn't
>check for it properl (I like Rui's 9/11 patch better than the above,
>so andrew, you can drop this patch in any case)
>
>thanks,
>-Len
>
>ps.  Sujith, shouldn't there be a MAINTAINERS for this driver with your
>name on it?
>
>
Hi Len,
I am also in agreement that Rui's 9/11 patch is the solution.
I'll be sending out patches you requested.
These can be applied over Rui's 9/11 patch.

Regards,
Sujith
	
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/