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@xxxxxxxxxx> 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-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html