Re: btrfs zero divide

[Thorsten Glaser]

Josef Bacik dixit:

>So stripe_len shouldn't be 0, if it is you have bigger problems :).

â

>Is this a corrupt fs or something? If there was some sort of

I donât think so, I can access and use that filesystem under 3.2
just fine (itâs what I created it under, too, so itâs possible
that itâs indeed corrupt and Linux 3.2 is just the same corrupt
to happen to make it work, e.g. wrong endianness used for stripe_len
which makes the upper 32 bit of that 64-bit value (usually 0) become
the lower 32 bit, or something like that).

I have access to that system, and itâs currently running as a
Debian/m68k buildd using said filesystem, but I can run commands
you tell me to diagnose/analyse it if it wonât get corrupted by
those.


Joe Perches dixit:

>Maybe use a temporary check in do_div

Mh. If nobody finds anything Iâll try that. (Doing things like
compiling a kernel and testing it takes about two days timeboxed
and some hours of active human effort, though, so Iâd like to
avoid guessing. Plus itâll disrupt running the Debian builddâ)

On second thoughts, this sort of check sounds like a good idea
to add to that file in general, depending on some debugging
CPPFLAG or Kconfig option. But Iâm not the authority on that.

bye,
//mirabilos
-- 
<ch> you introduced a merge commit        â<mika> % g rebase -i HEAD^^
<mika> sorry, no idea and rebasing just fscked â<mika> Segmentation
<ch> should have cloned into a clean repo      â  fault (core dumped)
<ch> if I rebase that now, it's really ugh     â<mika:#grml> wuahhhhhh
--
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/