From: roel kluin <roel.kluin@gmail.com>
To: Thomas Renninger <trenn@suse.de>
Cc: Valdis.Kletnieks@vt.edu, linux-acpi@vger.kernel.org
Subject: Re: [PATCH ?] ACPI: pr->id is unsigned
Date: Tue, 16 Sep 2008 22:48:19 -0400 [thread overview]
Message-ID: <48D06FF3.6010406@gmail.com> (raw)
In-Reply-To: <200809161045.35078.trenn@suse.de>
Thomas Renninger wrote:
> On Monday 15 September 2008 22:26:45 Valdis.Kletnieks@vt.edu wrote:
>> On Mon, 15 Sep 2008 21:32:20 EDT, roel kluin said:
>>> since pr->id is unsigned, shouldn't something like
>>> the patch below be applied?
>>>
>>> + BUG_ON((pr->id >= nr_cpu_ids) || ((unsigned long)pr->id < 0));
>> Under what conditions will the clause "(unsigned long)pr->id < 0)" be true,
>> and when will it be false? What will any sane optimizing compiler do?
ah, yes, remove it, I wasn't thinking. :-/
>> And *sometimes*, the *real* bug is that pr->id should be a signed quantity,
>> not an unsigned one, and the cast is just papering over the issue.
>>
>> In other words, the original line is almost certainly buggy. However, this
>> isn't the right fix. Somebody who actually understands the code will have
>> to decide what *should* be happening here (that's beyond my understanding
>> of that code)...
Thanks for correcting me, I should have verified that.
A prior mail, http://lkml.org/lkml/2008/9/9/136
brought me on a wrong line of thought:
[Quote (with ret as an unsigned long)]
if ((unsigned long)ret >= -ERESTART_RESTARTBLOCK)
This and similar ones are not wrong. The -constant is converted
to unsigned (which is a well-defined operation) after which an >=u
(greater-or-equal unsigned) is performed.
[End Quote]
> Just removing "pr->id < 0" condition should be the right fix.
>
> For such an easy patch in the ACPI subsystem it's enough to only post to
> the linux-acpi mailing list, no need to bother the whole world.
Ok, removed the rest of the world :-)
> Thanks for finding this, do you mind to repost a new version?
>
> Thomas
>
pr->id is unsigned
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index ee68ac5..9f203d3 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -667,7 +667,7 @@ static int __cpuinit acpi_processor_start(struct acpi_device *device)
return 0;
}
- BUG_ON((pr->id >= nr_cpu_ids) || (pr->id < 0));
+ BUG_ON(pr->id >= nr_cpu_ids);
/*
* Buggy BIOS check
next prev parent reply other threads:[~2008-09-16 20:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-16 1:32 [PATCH ?] ACPI: pr->id is unsigned roel kluin
2008-09-15 20:26 ` Valdis.Kletnieks
2008-09-16 8:45 ` Thomas Renninger
2008-09-17 2:48 ` roel kluin [this message]
2008-09-17 7:34 ` Thomas Renninger
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=48D06FF3.6010406@gmail.com \
--to=roel.kluin@gmail.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=linux-acpi@vger.kernel.org \
--cc=trenn@suse.de \
/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.