To follow up: Brought up the same kernel but with PROVE_LOCKING configured, and initialising the bcache set triggers the following lockdep warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 3716 at /home/kernel/linux-3.12.9/kernel/lockdep.c:708 __lock_acquire+0x1d0f/0x1d80() Modules linked in: brd nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc loop snd_pcm snd_page_alloc snd_timer snd soundcore i2c_piix4 i2c_core evdev virtio_balloon processor thermal_sys pcspkr button psmouse serio_raw ext4 crc16 mbcache jbd2 bcache sg sd_mod crc_t10dif crct10dif_common ata_generic floppy ata_piix libata virtio_pci virtio_ring 8139too scsi_mod uhci_hcd ehci_hcd virtio 8139cp mii usbcore usb_common CPU: 0 PID: 3716 Comm: bcache-register Not tainted 3.12-0.bpo.2-amd64 #1 Debian 3.12.9-1~bpo70+1 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 00000000000002c4 ffff880214baf798 ffffffff814fe566 ffff880214b8ad00 0000000000000000 ffff880214baf7d8 ffffffff81061cd7 ffffffff8109ada1 ffff8800dbbac8b0 ffff880214b8ad00 0000000000000000 0000000000000001 Call Trace: [<ffffffff814fe566>] dump_stack+0x46/0x58 [<ffffffff81061cd7>] warn_slowpath_common+0x87/0xb0 [<ffffffff8109ada1>] ? select_task_rq_fair+0x51/0x7f0 [<ffffffff81061d15>] warn_slowpath_null+0x15/0x20 [<ffffffff810cb1bf>] __lock_acquire+0x1d0f/0x1d80 [<ffffffff810c97a3>] ? __lock_acquire+0x2f3/0x1d80 [<ffffffff810cc164>] ? mark_held_locks+0x74/0x140 [<ffffffff81505c0a>] ? _raw_spin_unlock_irqrestore+0x3a/0x70 [<ffffffffa015a42e>] ? mca_reap+0x2e/0x1f0 [bcache] [<ffffffff810cb844>] lock_acquire+0x94/0x130 [<ffffffffa015a42e>] ? mca_reap+0x2e/0x1f0 [bcache] [<ffffffff8108ae1e>] down_write_trylock+0x5e/0x70 [<ffffffffa015a42e>] ? mca_reap+0x2e/0x1f0 [bcache] [<ffffffffa015a42e>] mca_reap+0x2e/0x1f0 [bcache] [<ffffffffa015a692>] mca_alloc+0xa2/0x560 [bcache] [<ffffffffa015bb72>] bch_btree_node_alloc+0xa2/0x2a0 [bcache] [<ffffffffa016ff19>] run_cache_set+0x769/0x960 [bcache] [<ffffffff812a531b>] ? idr_get_empty_slot+0x16b/0x3e0 [<ffffffffa0170d34>] register_cache_set+0x2b4/0x2c0 [bcache] [<ffffffffa01712b1>] register_cache+0x571/0x7a0 [bcache] [<ffffffff81184154>] ? kmem_cache_alloc_trace+0x1b4/0x1e0 [<ffffffffa0171b45>] ? register_bcache+0x665/0xec0 [bcache] [<ffffffffa0171b67>] register_bcache+0x687/0xec0 [bcache] [<ffffffff81210438>] ? sysfs_write_file+0xc8/0x160 [<ffffffff81159aab>] ? might_fault+0x3b/0x90 [<ffffffff812a653f>] kobj_attr_store+0xf/0x30 [<ffffffff81210451>] sysfs_write_file+0xe1/0x160 [<ffffffff8119b119>] vfs_write+0xc9/0x1e0 [<ffffffff8119b600>] SyS_write+0x50/0xa0 [<ffffffff8150e479>] system_call_fastpath+0x16/0x1b ---[ end trace 4a908a17006489d4 ]--- And the relevant part of lockdep.c says: list_for_each_entry(class, hash_head, hash_entry) { if (class->key == key) { /* * Huh! same key, different name? Did someone trample * on some memory? We're most confused. */ WARN_ON_ONCE(class->name != lock->name); So it looks like there's something about the btree initialisation that isn't quite kosher, maybe? -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html