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, Paul Jackson wrote:

> Zwane 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.
>
> So, if NR_CPUS is 3, and you pass an empty map to any_online_cpu()
> on an i386, you get back not 3, as expected, but 32 ??
>
> And this is because find_next_bit(0, 3, 0), for example, returns 32,
> correct ??
>
> Well ... no ... I must not be guessing your example right yet. Because
> in the above example, first_cpu(0) will (should ?) return with NR_CPUS,
> and the for_each_cpu_mask() inside any_online_cpu() will end there.
>
> Could you give me the rest of the numbers in a specific example?
>
> Please ...

Well you could have just tried it, all you needed to do was paste the code
for find_first_bit into a file and make a simple test case. Then plugging
in a value of 0x0 for the map. so in pseudocode for NR_CPUS = 3;

first_cpu(0) = next_cpu(0) = 32.

> Hmmm ... perhaps you're saying you're passing a non-zero map to
> any_online_cpu(), but that the bits set in what you pass aren't
> online, which would end up calling find_next_bit(). Yeah - that
> must be it.

Yes i did specify that in the original email.

> And indeed the i386 find_next_bit() code can't possibly be honoring a
> size < 32, because it doesn't even consider the size value until it has
> finished the first word without finding a set bit in the last 32-offset
> bits.
>
>
> > The "bug" in the i386 find_next_bit really
> > looks like a feature if you look at the code.
>
> What code, what feature, what bug ... Please be specific.

The find_next_bit code, the additional find_first_bit on the failure to
find a bit exit path and i'm referring to this bug, the one i'm reporting
now.

> If all this is so, then i386 find_next_bit() is wrong. Possibly other
> some arch's too -- it's not code that I can read easily.
>
> If not, then in addition to fixing cpumask.h, we'd better also consider
> whether we need to fix:

I was short on time to do a complete audit, the change to cpumask.h is a
necessity anyway.
-
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.086 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site