Re: [PATCH][2.6] first/next_cpu returns values > NR_CPUS

From: Zwane Mwaikambo (zwane_at_linuxpower.ca)
Date: 08/01/04

  • Next message: Zwane Mwaikambo: "Re: [PATCH][2.6] first/next_cpu returns values > NR_CPUS" 
    Date:	Sun, 1 Aug 2004 10:51:23 -0400 (EDT)
To: Paul Jackson <pj@sgi.com>

    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/

  • Next message: Zwane Mwaikambo: "Re: [PATCH][2.6] first/next_cpu returns values > NR_CPUS"

    Relevant Pages