Re: [PATCH v2] Btrfs: fix btrfs boot when compiled as built-in
On Sat, Feb 1, 2014 at 7:42 PM, Ahmet Inan wrote: >>> err = btrfs_hash_init(); >> Did you find out what err's value was? > Its -2 Thanks, that was very helpful Ahmet. > > Ahmet -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Btrfs: fix btrfs boot when compiled as built-in
>> err = btrfs_hash_init(); > Did you find out what err's value was? Its -2 Ahmet -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Btrfs: fix btrfs boot when compiled as built-in
On Sat, Feb 1, 2014 at 5:25 PM, Ahmet Inan
wrote:
>> I tried late_initcall too, both when built as a module and as
>> built-in. Seems to work too on my hardware.
> On my i3 (avx) and i7 (avx2) systems it works well too.
> Havent tested other, faster pre avx systems, besides that intel u7300
> system, which gave me troubles, yet.
>
>> Out of curiosity, what error were you getting exactly? Can you paste
>> the stack trace from dmesg?
> I get no error at all. But also no btrfs in /proc/filesystems.
>
> Here a part of the dmesg, but i cant see anything from btrfs there,
> besides my own printk:
>
> printk("hello");
> err = btrfs_hash_init();
Did you find out what err's value was?
That could give some more insight, right now I don't fully understand
what happened.
Thanks
>
> ...
> [0.488837] sha1_ssse3: Neither AVX nor SSSE3 is available/usable.
> [0.489075] AVX instructions are not detected.
> [0.489284] AVX instructions are not detected.
> [0.490126] audit: initializing netlink socket (disabled)
> [0.490345] type=2000 audit(1391274060.489:1): initialized
> [0.518163] squashfs: version 4.0 (2009/01/31) Phillip Lougher
> [0.518626] Installing knfsd (copyright (C) 1996 o...@monad.swb.de).
> [0.518973] NTFS driver 2.1.30 [Flags: R/W].
> [0.519312] SGI XFS with security attributes, large block/inode
> numbers, no debug enabled
> [0.519989] NILFS version 2 loaded
> [0.520195] hello
> [0.520654] msgmni has been set to 3985
> [0.522639] NET: Registered protocol family 38
> [0.522948] Block layer SCSI generic (bsg) driver version 0.4
> loaded (major 250)
> [0.523364] io scheduler noop registered
> [0.523582] io scheduler deadline registered
> [0.523830] io scheduler cfq registered (default)
> ...
>
> And here, if i use late_initcall:
>
> ...
> [0.992166] Key type dns_resolver registered
> [0.993168] registered taskstats version 1
> [0.993752] hello
> [0.993932] bio: create slab at 1
> [0.995293] Btrfs loaded
> [0.996004] rtc_cmos 00:00: setting system clock to 2014-02-01
> 17:09:57 UTC (1391274597)
> [0.997902] Freeing unused kernel memory: 3060K (826f9000 -
> 829f6000)
> ...
>
> Attached are both full dmesg logs.
>
> Ahmet
--
Filipe David Manana,
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Btrfs: fix btrfs boot when compiled as built-in
On Sat, Feb 1, 2014 at 10:29 AM, Ahmet Inan wrote: > okay, putting late_initcall instead of module_init fixes it for me, > but this is something you guys should decide how to handle: > > //module_init(init_btrfs_fs) > late_initcall(init_btrfs_fs); Thanks for reporting and testing Ahmet. I tried late_initcall too, both when built as a module and as built-in. Seems to work too on my hardware. Out of curiosity, what error were you getting exactly? Can you paste the stack trace from dmesg? > > Ahmet -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Btrfs: fix btrfs boot when compiled as built-in
okay, putting late_initcall instead of module_init fixes it for me, but this is something you guys should decide how to handle: //module_init(init_btrfs_fs) late_initcall(init_btrfs_fs); Ahmet -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Btrfs: fix btrfs boot when compiled as built-in
There is still a problem when btrfs is built-in: err = btrfs_hash_init(); Will not succeed if run on an slow cpu (intel u7300) or in qemu if btrfs is built-in: # qemu-kvm -enable-kvm -usbdevice tablet -m 2048 -smp 2 -sdl -kernel /usr/src/linux/arch/x86/boot/bzImage But it works, when btrfs is a module. I really do not want to go back using modules in my initramfs .. There must be a way to move init_btrfs_fs to the end of Linux built-in initializations .. Ahmet -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Btrfs: fix btrfs boot when compiled as built-in
On Thu, Jan 30, 2014 at 01:18:04PM +, Filipe David Manana wrote: > On Thu, Jan 30, 2014 at 3:11 AM, Darrick J. Wong > wrote: > > On Sun, Jan 12, 2014 at 02:22:46AM +, Filipe David Borba Manana wrote: > >> 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: [] crc32c+0xc/0x6b > >> [2.028684] PGD 0 > >> [2.028684] Oops: [#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: 88000edba100 ti: 88000edd6000 task.ti: > >> 88000edd6000 > >> [2.028684] RIP: 0010:[] [] > >> crc32c+0xc/0x6b > >> [2.028684] RSP: :88000edd7e58 EFLAGS: 00010246 > >> [2.028684] RAX: RBX: 82295550 RCX: > >> > >> [2.028684] RDX: 0011 RSI: 81efe393 RDI: > >> fffe > >> [2.028684] RBP: 88000edd7e60 R08: 0003 R09: > >> 00015d20 > >> [2.028684] R10: 81ef225e R11: 811b0222 R12: > >> > >> [2.028684] R13: 0239 R14: R15: > >> > >> [2.028684] FS: () GS:88000fa0() > >> knlGS: > >> [2.028684] CS: 0010 DS: ES: CR0: 8005003b > >> [2.028684] CR2: CR3: 0220c000 CR4: > >> 06f0 > >> [2.028684] Stack: > >> [2.028684] 82295550 88000edd7e80 8238af62 > >> 8238ac05 > >> [2.028684] 88000edd7e98 8238ac0f > >> 8238ac05 > >> [2.028684] 88000edd7f08 810002ba 88000edd7f00 > >> 810e2404 > >> [2.028684] Call Trace: > >> [2.028684] [] btrfs_props_init+0x4f/0x96 > >> [2.028684] [] ? > >> ftrace_define_fields_btrfs_space_reservation+0x145/0x145 > >> [2.028684] [] init_btrfs_fs+0xa/0xf0 > >> [2.028684] [] ? > >> ftrace_define_fields_btrfs_space_reservation+0x145/0x145 > >> [2.028684] [] do_one_initcall+0xa4/0x13a > >> [2.028684] [] ? parse_args+0x25f/0x33d > >> [2.028684] [] kernel_init_freeable+0x1aa/0x230 > >> [2.028684] [] ? do_early_param+0x88/0x88 > >> [2.028684] [] ? rest_init+0x89/0x89 > >> [2.028684] [] 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. > > > > Sorry, I didn't even see this until your other patch today... > > > > Yes, ext4 bypasses libcrc32c, but notice how ext4/jbd2 only call > > crypto_alloc_shash() when you mount the filesystem. This silly trick > > enables > > ext4 to take advantage of faster crc32c implementations that don't get > > loaded > > until after the initial insmod, just in case you do this: > > > > # modprobe btrfs > > # mount /dev/X /<-- / uses software crc32c implementation > > # modprobe crc32c-intel > > # mount /dev/Y /home<-- /home still uses software crc32c, > > because > > *tfm still points to the sw > > implementation! > > > > Of course, one could argue that this is a distro problem, and that the > > initramfs or kernel config should take care to load the appropriate hardware > > accelerated drivers /before/ btrfs. > > > > On the other hand, btrfs might as well always enjoy the fastest > > implementation > > that it can get its hands on. > > Thanks Darrick, that's very useful information. > > So, if I understood it correctly, before this change btrfs was using > libcrc32c, which is initialized only once and therefore it's possible > it wouldn't use crc32c-intel - if crc32c-intel was built as a module > and not loaded before libcrc32c is initialized. > > Also that ext4 approach, of using crypto_alloc_shash() on each mount > (and make the result accessible via super block structure) doesn't > solve the case where the partition is mounted before crc32c-intel is > loaded but then it's never unmounted and mounted again (like a root or > home p
Re: [PATCH v2] Btrfs: fix btrfs boot when compiled as built-in
On Thu, Jan 30, 2014 at 1:18 PM, Filipe David Manana wrote: > On Thu, Jan 30, 2014 at 3:11 AM, Darrick J. Wong > wrote: >> On Sun, Jan 12, 2014 at 02:22:46AM +, Filipe David Borba Manana wrote: >>> 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: [] crc32c+0xc/0x6b >>> [2.028684] PGD 0 >>> [2.028684] Oops: [#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: 88000edba100 ti: 88000edd6000 task.ti: >>> 88000edd6000 >>> [2.028684] RIP: 0010:[] [] >>> crc32c+0xc/0x6b >>> [2.028684] RSP: :88000edd7e58 EFLAGS: 00010246 >>> [2.028684] RAX: RBX: 82295550 RCX: >>> >>> [2.028684] RDX: 0011 RSI: 81efe393 RDI: >>> fffe >>> [2.028684] RBP: 88000edd7e60 R08: 0003 R09: >>> 00015d20 >>> [2.028684] R10: 81ef225e R11: 811b0222 R12: >>> >>> [2.028684] R13: 0239 R14: R15: >>> >>> [2.028684] FS: () GS:88000fa0() >>> knlGS: >>> [2.028684] CS: 0010 DS: ES: CR0: 8005003b >>> [2.028684] CR2: CR3: 0220c000 CR4: >>> 06f0 >>> [2.028684] Stack: >>> [2.028684] 82295550 88000edd7e80 8238af62 >>> 8238ac05 >>> [2.028684] 88000edd7e98 8238ac0f >>> 8238ac05 >>> [2.028684] 88000edd7f08 810002ba 88000edd7f00 >>> 810e2404 >>> [2.028684] Call Trace: >>> [2.028684] [] btrfs_props_init+0x4f/0x96 >>> [2.028684] [] ? >>> ftrace_define_fields_btrfs_space_reservation+0x145/0x145 >>> [2.028684] [] init_btrfs_fs+0xa/0xf0 >>> [2.028684] [] ? >>> ftrace_define_fields_btrfs_space_reservation+0x145/0x145 >>> [2.028684] [] do_one_initcall+0xa4/0x13a >>> [2.028684] [] ? parse_args+0x25f/0x33d >>> [2.028684] [] kernel_init_freeable+0x1aa/0x230 >>> [2.028684] [] ? do_early_param+0x88/0x88 >>> [2.028684] [] ? rest_init+0x89/0x89 >>> [2.028684] [] 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. >> >> Sorry, I didn't even see this until your other patch today... >> >> Yes, ext4 bypasses libcrc32c, but notice how ext4/jbd2 only call >> crypto_alloc_shash() when you mount the filesystem. This silly trick enables >> ext4 to take advantage of faster crc32c implementations that don't get loaded >> until after the initial insmod, just in case you do this: >> >> # modprobe btrfs >> # mount /dev/X /<-- / uses software crc32c implementation >> # modprobe crc32c-intel >> # mount /dev/Y /home<-- /home still uses software crc32c, because >> *tfm still points to the sw >> implementation! >> >> Of course, one could argue that this is a distro problem, and that the >> initramfs or kernel config should take care to load the appropriate hardware >> accelerated drivers /before/ btrfs. >> >> On the other hand, btrfs might as well always enjoy the fastest >> implementation >> that it can get its hands on. > > Thanks Darrick, that's very useful information. > > So, if I understood it correctly, before this change btrfs was using > libcrc32c, which is initialized only once and therefore it's possible > it wouldn't use crc32c-intel - if crc32c-intel was built as a module > and not loaded before libcrc32c is initialized. > > Also that ext4 approach, of using crypto_alloc_shash() on each mount > (and make the result accessible via super block structure) doesn't > solve the case where the partition is mounted before crc32c-intel is > loaded but then it's never unmounted and mounted again (like a root or > home partition). By solve I mean not profiting from intel's hardware > based crc32c. > > I suppose that if crc32c-intel is b
Re: [PATCH v2] Btrfs: fix btrfs boot when compiled as built-in
On Thu, Jan 30, 2014 at 3:11 AM, Darrick J. Wong wrote: > On Sun, Jan 12, 2014 at 02:22:46AM +, Filipe David Borba Manana wrote: >> 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: [] crc32c+0xc/0x6b >> [2.028684] PGD 0 >> [2.028684] Oops: [#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: 88000edba100 ti: 88000edd6000 task.ti: >> 88000edd6000 >> [2.028684] RIP: 0010:[] [] >> crc32c+0xc/0x6b >> [2.028684] RSP: :88000edd7e58 EFLAGS: 00010246 >> [2.028684] RAX: RBX: 82295550 RCX: >> >> [2.028684] RDX: 0011 RSI: 81efe393 RDI: >> fffe >> [2.028684] RBP: 88000edd7e60 R08: 0003 R09: >> 00015d20 >> [2.028684] R10: 81ef225e R11: 811b0222 R12: >> >> [2.028684] R13: 0239 R14: R15: >> >> [2.028684] FS: () GS:88000fa0() >> knlGS: >> [2.028684] CS: 0010 DS: ES: CR0: 8005003b >> [2.028684] CR2: CR3: 0220c000 CR4: >> 06f0 >> [2.028684] Stack: >> [2.028684] 82295550 88000edd7e80 8238af62 >> 8238ac05 >> [2.028684] 88000edd7e98 8238ac0f >> 8238ac05 >> [2.028684] 88000edd7f08 810002ba 88000edd7f00 >> 810e2404 >> [2.028684] Call Trace: >> [2.028684] [] btrfs_props_init+0x4f/0x96 >> [2.028684] [] ? >> ftrace_define_fields_btrfs_space_reservation+0x145/0x145 >> [2.028684] [] init_btrfs_fs+0xa/0xf0 >> [2.028684] [] ? >> ftrace_define_fields_btrfs_space_reservation+0x145/0x145 >> [2.028684] [] do_one_initcall+0xa4/0x13a >> [2.028684] [] ? parse_args+0x25f/0x33d >> [2.028684] [] kernel_init_freeable+0x1aa/0x230 >> [2.028684] [] ? do_early_param+0x88/0x88 >> [2.028684] [] ? rest_init+0x89/0x89 >> [2.028684] [] 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. > > Sorry, I didn't even see this until your other patch today... > > Yes, ext4 bypasses libcrc32c, but notice how ext4/jbd2 only call > crypto_alloc_shash() when you mount the filesystem. This silly trick enables > ext4 to take advantage of faster crc32c implementations that don't get loaded > until after the initial insmod, just in case you do this: > > # modprobe btrfs > # mount /dev/X /<-- / uses software crc32c implementation > # modprobe crc32c-intel > # mount /dev/Y /home<-- /home still uses software crc32c, because > *tfm still points to the sw > implementation! > > Of course, one could argue that this is a distro problem, and that the > initramfs or kernel config should take care to load the appropriate hardware > accelerated drivers /before/ btrfs. > > On the other hand, btrfs might as well always enjoy the fastest implementation > that it can get its hands on. Thanks Darrick, that's very useful information. So, if I understood it correctly, before this change btrfs was using libcrc32c, which is initialized only once and therefore it's possible it wouldn't use crc32c-intel - if crc32c-intel was built as a module and not loaded before libcrc32c is initialized. Also that ext4 approach, of using crypto_alloc_shash() on each mount (and make the result accessible via super block structure) doesn't solve the case where the partition is mounted before crc32c-intel is loaded but then it's never unmounted and mounted again (like a root or home partition). By solve I mean not profiting from intel's hardware based crc32c. I suppose that if crc32c-intel is built-in (i.e. not as a module) that either with the current approach (after this patch) or with the old approach, we'll be using crc32c-intel. Is there any way to verify this? > > (Also I
Re: [PATCH v2] Btrfs: fix btrfs boot when compiled as built-in
On Sun, Jan 12, 2014 at 02:22:46AM +, Filipe David Borba Manana wrote: > 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: [] crc32c+0xc/0x6b > [2.028684] PGD 0 > [2.028684] Oops: [#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: 88000edba100 ti: 88000edd6000 task.ti: > 88000edd6000 > [2.028684] RIP: 0010:[] [] > crc32c+0xc/0x6b > [2.028684] RSP: :88000edd7e58 EFLAGS: 00010246 > [2.028684] RAX: RBX: 82295550 RCX: > > [2.028684] RDX: 0011 RSI: 81efe393 RDI: > fffe > [2.028684] RBP: 88000edd7e60 R08: 0003 R09: > 00015d20 > [2.028684] R10: 81ef225e R11: 811b0222 R12: > > [2.028684] R13: 0239 R14: R15: > > [2.028684] FS: () GS:88000fa0() > knlGS: > [2.028684] CS: 0010 DS: ES: CR0: 8005003b > [2.028684] CR2: CR3: 0220c000 CR4: > 06f0 > [2.028684] Stack: > [2.028684] 82295550 88000edd7e80 8238af62 > 8238ac05 > [2.028684] 88000edd7e98 8238ac0f > 8238ac05 > [2.028684] 88000edd7f08 810002ba 88000edd7f00 > 810e2404 > [2.028684] Call Trace: > [2.028684] [] btrfs_props_init+0x4f/0x96 > [2.028684] [] ? > ftrace_define_fields_btrfs_space_reservation+0x145/0x145 > [2.028684] [] init_btrfs_fs+0xa/0xf0 > [2.028684] [] ? > ftrace_define_fields_btrfs_space_reservation+0x145/0x145 > [2.028684] [] do_one_initcall+0xa4/0x13a > [2.028684] [] ? parse_args+0x25f/0x33d > [2.028684] [] kernel_init_freeable+0x1aa/0x230 > [2.028684] [] ? do_early_param+0x88/0x88 > [2.028684] [] ? rest_init+0x89/0x89 > [2.028684] [] 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. Sorry, I didn't even see this until your other patch today... Yes, ext4 bypasses libcrc32c, but notice how ext4/jbd2 only call crypto_alloc_shash() when you mount the filesystem. This silly trick enables ext4 to take advantage of faster crc32c implementations that don't get loaded until after the initial insmod, just in case you do this: # modprobe btrfs # mount /dev/X /<-- / uses software crc32c implementation # modprobe crc32c-intel # mount /dev/Y /home<-- /home still uses software crc32c, because *tfm still points to the sw implementation! Of course, one could argue that this is a distro problem, and that the initramfs or kernel config should take care to load the appropriate hardware accelerated drivers /before/ btrfs. On the other hand, btrfs might as well always enjoy the fastest implementation that it can get its hands on. (Also I suppose metadata_csum is optional in ext4/jbd2...) --D > > Verified this works both when btrfs is built-in and when it's loadable kernel > module. > > Signed-off-by: Filipe David Borba Manana > --- > > V2: Removed unnecessary __exit qualifier. > > fs/btrfs/Kconfig |3 ++- > fs/btrfs/Makefile |2 +- > fs/btrfs/extent-tree.c |6 +++--- > fs/btrfs/hash.c| 49 > > fs/btrfs/hash.h| 11 --- > fs/btrfs/super.c | 10 +- > 6 files changed, 72 insertions(+), 9 deletions(-) > create mode 100644 fs/btrfs/hash.c > > diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig > index aa976ec..a66768e 100644 > --- a/fs/btrfs/Kconfig > +++ b/fs/btrfs/Kconfig > @@ -1,6 +1,7 @@ > config BTRFS_FS > tristate "Btrfs filesystem support" > - select LIBCRC32C > + select CRYPTO > + select CRYPTO_CRC32C > select ZLIB_INFLATE > select ZLIB_DEFLATE > select LZO_COMPRESS > diff --git a/fs/btrfs/Makefile b/
[PATCH v2] Btrfs: fix btrfs boot when compiled as built-in
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: [] crc32c+0xc/0x6b [2.028684] PGD 0 [2.028684] Oops: [#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: 88000edba100 ti: 88000edd6000 task.ti: 88000edd6000 [2.028684] RIP: 0010:[] [] crc32c+0xc/0x6b [2.028684] RSP: :88000edd7e58 EFLAGS: 00010246 [2.028684] RAX: RBX: 82295550 RCX: [2.028684] RDX: 0011 RSI: 81efe393 RDI: fffe [2.028684] RBP: 88000edd7e60 R08: 0003 R09: 00015d20 [2.028684] R10: 81ef225e R11: 811b0222 R12: [2.028684] R13: 0239 R14: R15: [2.028684] FS: () GS:88000fa0() knlGS: [2.028684] CS: 0010 DS: ES: CR0: 8005003b [2.028684] CR2: CR3: 0220c000 CR4: 06f0 [2.028684] Stack: [2.028684] 82295550 88000edd7e80 8238af62 8238ac05 [2.028684] 88000edd7e98 8238ac0f 8238ac05 [2.028684] 88000edd7f08 810002ba 88000edd7f00 810e2404 [2.028684] Call Trace: [2.028684] [] btrfs_props_init+0x4f/0x96 [2.028684] [] ? ftrace_define_fields_btrfs_space_reservation+0x145/0x145 [2.028684] [] init_btrfs_fs+0xa/0xf0 [2.028684] [] ? ftrace_define_fields_btrfs_space_reservation+0x145/0x145 [2.028684] [] do_one_initcall+0xa4/0x13a [2.028684] [] ? parse_args+0x25f/0x33d [2.028684] [] kernel_init_freeable+0x1aa/0x230 [2.028684] [] ? do_early_param+0x88/0x88 [2.028684] [] ? rest_init+0x89/0x89 [2.028684] [] 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: Filipe David Borba Manana --- V2: Removed unnecessary __exit qualifier. fs/btrfs/Kconfig |3 ++- fs/btrfs/Makefile |2 +- fs/btrfs/extent-tree.c |6 +++--- fs/btrfs/hash.c| 49 fs/btrfs/hash.h| 11 --- fs/btrfs/super.c | 10 +- 6 files changed, 72 insertions(+), 9 deletions(-) create mode 100644 fs/btrfs/hash.c diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig index aa976ec..a66768e 100644 --- a/fs/btrfs/Kconfig +++ b/fs/btrfs/Kconfig @@ -1,6 +1,7 @@ config BTRFS_FS tristate "Btrfs filesystem support" - select LIBCRC32C + select CRYPTO + select CRYPTO_CRC32C select ZLIB_INFLATE select ZLIB_DEFLATE select LZO_COMPRESS diff --git a/fs/btrfs/Makefile b/fs/btrfs/Makefile index af7f000..f341a98 100644 --- a/fs/btrfs/Makefile +++ b/fs/btrfs/Makefile @@ -9,7 +9,7 @@ btrfs-y += super.o ctree.o extent-tree.o print-tree.o root-tree.o dir-item.o \ export.o tree-log.o free-space-cache.o zlib.o lzo.o \ compression.o delayed-ref.o relocation.o delayed-inode.o scrub.o \ reada.o backref.o ulist.o qgroup.o send.o dev-replace.o raid56.o \ - uuid-tree.o props.o + uuid-tree.o props.o hash.o btrfs-$(CONFIG_BTRFS_FS_POSIX_ACL) += acl.o btrfs-$(CONFIG_BTRFS_FS_CHECK_INTEGRITY) += check-integrity.o diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 77acc08..db19ed7 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -1072,11 +1072,11 @@ static u64 hash_extent_data_ref(u64 root_objectid, u64 owner, u64 offset) __le64 lenum; lenum = cpu_to_le64(root_objectid); - high_crc = crc32c(high_crc, &lenum, sizeof(lenum)); + high_crc = btrfs_crc32c(high_crc, &lenum, sizeof(lenum)); lenum = cpu_to_le64(owner); - low_crc = crc32c(low_crc, &lenum, sizeof(lenum)); + low_crc = btrfs_crc32c(low_crc, &lenum, sizeof(lenum)); lenum = cpu_to_le64(offset); - low_crc = crc3
