lkml.org 
[lkml]   [2006]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Boot failure with ext2 and initrds
    On Wed, Nov 15, 2006 at 11:22:28PM -0800, Andrew Morton wrote:
    > On Wed, 15 Nov 2006 22:55:43 -0800
    > Mingming Cao <cmm@us.ibm.com> wrote:
    >
    > > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
    > > number of the range to search, not the lengh of the range. maxblocks
    > > get passed to ext2_find_next_zero_bit(), where it expecting to take the
    > > _size_ of the range to search instead...
    > >
    > > Something like this: (this is not a patch)
    > > @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
    > > ext2_grpblk_t next;
    > >
    > > - next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
    > > + next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1, start);
    > > if (next >= maxblocks)
    > > return -1;
    > > return next;
    > > }
    >
    > yes, the `size' arg to find_next_zero_bit() represents the number of bits
    > to scan at `offset'.

    Are you sure? That's not the way it's implemented in many architectures.
    find_next_*_bit() has always taken "address, maximum offset, starting offset"
    and always has returned "next offset".

    Just look at arch/i386/lib/bitops.c:

    int find_next_zero_bit(const unsigned long *addr, int size, int offset)
    {
    unsigned long * p = ((unsigned long *) addr) + (offset >> 5);
    int set = 0, bit = offset & 31, res;
    ...
    /*
    * No zero yet, search remaining full bytes for a zero
    */
    res = find_first_zero_bit (p, size - 32 * (p - (unsigned long *) addr));
    return (offset + set + res);
    }

    So for the case that "offset" is aligned to a "long" boundary, that gives us:

    res = find_first_zero_bit(addr + (offset>>5),
    size - 32 * (addr + (offset>>5) - addr));

    or:

    res = find_first_zero_bit(addr + (offset>>5), size - (offset & ~31));

    So, size _excludes_ offset.

    Now, considering the return value, "res" above will be relative to
    "addr + (offset>>5)". However, we add "offset" on to that, so it's
    relative to addr + (offset bits).

    --
    Russell King
    Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
    maintainer of: 2.6 Serial core
    -
    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: 2006-11-16 13:37    [W:0.040 / U:91.188 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site