lkml.org 
[lkml]   [2004]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH][2.6] first/next_cpu returns values > NR_CPUS
On Sun, 1 Aug 2004, William Lee Irwin III wrote:

> On Sun, Aug 01, 2004 at 03:22:56AM -0400, Zwane Mwaikambo wrote:
> > NR_CPUS was 3, the test case may as well be passing first_cpu or next_cpu
> > a value of 0 for the map. The "bug" in the i386 find_next_bit really
> > looks like a feature if you look at the code.
>
> Hmm. I'm actually somewhat puzzled by this also. Shouldn't things only
> check for inequalities between the results of these and NR_CPUS? i.e.
> things like:
> if (any_online_cpu(cpus) >= NR_CPUS)
> and
> for (cpu = first_cpu(cpus); cpu < NR_CPUS; cpu = next_cpu(cpus))
> etc.?
>
> Maybe the few callers that are sensitive to the precise return value
> should use min_t(int, NR_CPUS, ...) instead of all callers taking the
> branch on behalf of those few.

The problem is that next_cpu(0) will assign the incorrect value of '32'
to variable cpu so when you exit the loop, you'll have some silly number.
This really should be covered in the API, especially since that's what the
API states is the expected behaviour.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.068 / U:0.668 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site