Yet another attempt to get a response from Andrew. It is rather
important that you DO respond to this.
On Sat, Nov 25, 2006 at 02:59:16PM +0000, Russell King wrote:
> On Thu, Nov 16, 2006 at 12:34:48PM +0000, Russell King wrote:
> > 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).
>
> Andrew,
>
> Please respond to the above. If what you say is correct then all
> architectures need their bitops fixing to fit ext2's requirements.
>
> --
> Russell King
> Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
> maintainer of:
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
-
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
