On Tue, 2008-07-22 at 10:35 -0400, David Woodhouse wrote:
> On Tue, 2008-07-22 at 06:21 -0400, Chris Mason wrote:
> > What kind of box is this? The current code should be fine on big
> > endian, but that hasn't been tested recently.
>
> It's a PowerBook (ppc32).
>
> The bug is a BUG_ON(spin_trylock(&tree->lock)) in
> lookup_extent_mapping() -- I didn't think endianness was a likely factor
> in that.
I think the caller is doing this:
spin_lock(&map_tree->map_tree.lock);
em = lookup_extent_mapping(&map_tree->map_tree, logical, 1);
spin_unlock(&map_tree->map_tree.lock);
> Being uniprocessor might be though -- don't we hard-code spin_trylock()
> to _always_ succeed on UP, unless spinlock debugging is enabled?
>
> I think that test needs to happen only if spinlocks aren't no-ops. Or
> have you moved past the point where you need it now, so can we just
> remove it?
>
Well, the test is there to make sure the caller is doing the right
thing. Before we remove it, I'd like to understand why it is failing.
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
