On Tue, Aug 30, 2016 at 5:58 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: > On Tue, Aug 30, 2016 at 02:56:45PM +0200, John Paul Adrian Glaubitz wrote: >> On 08/30/2016 02:42 PM, Anatoly Pugachev wrote: >> > ../../e2fsck/recovery.c:866 >> > 866 blocknr = ext2fs_be64_to_cpu(* ((__u64 >> > *) (bh->b_data+offset))); >> >> The reason is that this expression is casting "char * b_data" [1] into u64 [2] >> which provokes unaligned access. Since such expression are often inevitable, >> it's probably best to modify the conversion macros in bitops.h [3] to be >> safe against unaligned accesses. > > I don't think that's it. b_data is a 4k buffer should be 8 byte > aligned. For a file system with 64-bit blocks (which you presumably > have since we're on the be64 path as shown in your debugger output) > the offset is initially set to 16, and is incremented in chunks of 8 > bytes. So there shouldn't be any unaligned access. > > Since you are able to provke this in a debugger, can you have gdb > print out the value of bh->b_data and offset, so we can be sure what's > going on? (gdb) p bh->b_data $1 = "\300;9\230\000\000\000\005\000\000\253\204\000\000\000\070\000\000\000\000\000\000$\022\000\000\000\000\000\000$<\000\000\000\000\000\000$\270\000\000\000\000\000\000$]\000\000\000\000\000\000$\024", '\000' <repeats 967 times> (gdb) p offset $2 = 16 (gdb) p *bh->b_data $3 = -64 '\300' (gdb) p *(bh->b_data+offset) $6 = 0 '\000' -- 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
