From: Thomas Renninger <trenn@suse.de>
To: Valdis.Kletnieks@vt.edu
Cc: roel kluin <roel.kluin@gmail.com>,
ak@linux.intel.com, lenb@kernel.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH ?] ACPI: pr->id is unsigned
Date: Tue, 16 Sep 2008 10:45:31 +0200 [thread overview]
Message-ID: <200809161045.35078.trenn@suse.de> (raw)
In-Reply-To: <128370.1221510405@turing-police.cc.vt.edu>
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?
>
> 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)...
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.
Thanks for finding this, do you mind to repost a new version?
Thomas
next prev parent reply other threads:[~2008-09-16 8:45 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 [this message]
2008-09-17 2:48 ` roel kluin
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=200809161045.35078.trenn@suse.de \
--to=trenn@suse.de \
--cc=Valdis.Kletnieks@vt.edu \
--cc=ak@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=roel.kluin@gmail.com \
/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.