• F
    Btrfs: fix btrfs boot when compiled as built-in · 14a958e6
    Filipe David Borba Manana 提交于
    After the change titled "Btrfs: add support for inode properties", if
    btrfs was built-in the kernel (i.e. not as a module), it would cause a
    kernel panic, as reported recently by Fengguang:
    
    [    2.024722] BUG: unable to handle kernel NULL pointer dereference at           (null)
    [    2.027814] IP: [<ffffffff81501594>] crc32c+0xc/0x6b
    [    2.028684] PGD 0
    [    2.028684] Oops: 0000 [#1] SMP
    [    2.028684] Modules linked in:
    [    2.028684] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc7-04795-ga7b57c2 #1
    [    2.028684] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
    [    2.028684] task: ffff88000edba100 ti: ffff88000edd6000 task.ti: ffff88000edd6000
    [    2.028684] RIP: 0010:[<ffffffff81501594>]  [<ffffffff81501594>] crc32c+0xc/0x6b
    [    2.028684] RSP: 0000:ffff88000edd7e58  EFLAGS: 00010246
    [    2.028684] RAX: 0000000000000000 RBX: ffffffff82295550 RCX: 0000000000000000
    [    2.028684] RDX: 0000000000000011 RSI: ffffffff81efe393 RDI: 00000000fffffffe
    [    2.028684] RBP: ffff88000edd7e60 R08: 0000000000000003 R09: 0000000000015d20
    [    2.028684] R10: ffffffff81ef225e R11: ffffffff811b0222 R12: ffffffffffffffff
    [    2.028684] R13: 0000000000000239 R14: 0000000000000000 R15: 0000000000000000
    [    2.028684] FS:  0000000000000000(0000) GS:ffff88000fa00000(0000) knlGS:0000000000000000
    [    2.028684] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [    2.028684] CR2: 0000000000000000 CR3: 000000000220c000 CR4: 00000000000006f0
    [    2.028684] Stack:
    [    2.028684]  ffffffff82295550 ffff88000edd7e80 ffffffff8238af62 ffffffff8238ac05
    [    2.028684]  0000000000000000 ffff88000edd7e98 ffffffff8238ac0f ffffffff8238ac05
    [    2.028684]  ffff88000edd7f08 ffffffff810002ba ffff88000edd7f00 ffffffff810e2404
    [    2.028684] Call Trace:
    [    2.028684]  [<ffffffff8238af62>] btrfs_props_init+0x4f/0x96
    [    2.028684]  [<ffffffff8238ac05>] ? ftrace_define_fields_btrfs_space_reservation+0x145/0x145
    [    2.028684]  [<ffffffff8238ac0f>] init_btrfs_fs+0xa/0xf0
    [    2.028684]  [<ffffffff8238ac05>] ? ftrace_define_fields_btrfs_space_reservation+0x145/0x145
    [    2.028684]  [<ffffffff810002ba>] do_one_initcall+0xa4/0x13a
    [    2.028684]  [<ffffffff810e2404>] ? parse_args+0x25f/0x33d
    [    2.028684]  [<ffffffff8234cf75>] kernel_init_freeable+0x1aa/0x230
    [    2.028684]  [<ffffffff8234c785>] ? do_early_param+0x88/0x88
    [    2.028684]  [<ffffffff819f61b5>] ? rest_init+0x89/0x89
    [    2.028684]  [<ffffffff819f61c3>] kernel_init+0xe/0x109
    
    The issue here is that the initialization function of btrfs (super.c:init_btrfs_fs)
    started using crc32c (from lib/libcrc32c.c). But when it needs to call crc32c (as
    part of the properties initialization routine), the libcrc32c is not yet initialized,
    so crc32c derreferenced a NULL pointer (lib/libcrc32c.c:tfm), causing the kernel
    panic on boot.
    
    The approach to fix this is to use crypto component directly to use its crc32c (which
    is basically what lib/libcrc32c.c is, a wrapper around crypto). This is what ext4 is
    doing as well, it uses crypto directly to get crc32c functionality.
    
    Verified this works both when btrfs is built-in and when it's loadable kernel module.
    Signed-off-by: NFilipe David Borba Manana <fdmanana@gmail.com>
    Signed-off-by: NJosef Bacik <jbacik@fb.com>
    Signed-off-by: NChris Mason <clm@fb.com>
    14a958e6
extent-tree.c 238.3 KB