Messages in this thread | | | Date | Sun, 1 Aug 2004 10:51:23 -0400 (EDT) | From | Zwane Mwaikambo <> | Subject | Re: [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/
| |