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. 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? T'would be nice if lockdep or sparse could handle this for us -- we already have annotations which indicate that a function 'acquires' or 'releases' locks. I wonder if we could also do 'requires'? -- dwmw2 -- 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
