[lkml]   [2004]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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
More majordomo info at
Please read the FAQ at

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