Re: lockdep warning in btrfs in 4.8-rc3

[Chris Mason <clm@fb.com>]

On 09/08/2016 08:50 PM, Dave Jones wrote:
> On Thu, Sep 08, 2016 at 08:58:48AM -0400, Chris Mason wrote:
>  > On 09/08/2016 07:50 AM, Christian Borntraeger wrote:
>  > > On 09/08/2016 01:48 PM, Christian Borntraeger wrote:
>  > >> Chris,
>  > >>
>  > >> with 4.8-rc3 I get the following on an s390 box:
>  > >
>  > > Sorry for the noise, just saw the fix in your pull request.
>  > >
>  >
>  > The lockdep splat is still there, we'll need to annotate this one a little.
>
> Here's another one (unrelated?) that I've not seen before today:
>
> WARNING: CPU: 1 PID: 10664 at kernel/locking/lockdep.c:704 register_lock_class+0x33f/0x510
> CPU: 1 PID: 10664 Comm: kworker/u8:5 Not tainted 4.8.0-rc5-think+ #2
> Workqueue: writeback wb_workfn (flush-btrfs-1)
>  0000000000000097 00000000b97fbad3 ffff88013b8c3770 ffffffffa63d3ab1
>  0000000000000000 0000000000000000 ffffffffa6bf1792 ffffffffa60df22f
>  ffff88013b8c37b0 ffffffffa60897a0 000002c0b97fbad3 ffffffffa6bf1792
> Call Trace:
>  [<ffffffffa63d3ab1>] dump_stack+0x6c/0x9b
>  [<ffffffffa60df22f>] ? register_lock_class+0x33f/0x510
>  [<ffffffffa60897a0>] __warn+0x110/0x130
>  [<ffffffffa608992c>] warn_slowpath_null+0x2c/0x40
>  [<ffffffffa60df22f>] register_lock_class+0x33f/0x510
>  [<ffffffffa639d9ce>] ? bio_add_page+0x7e/0x120
>  [<ffffffffa60e082b>] __lock_acquire.isra.32+0x5b/0x8c0
>  [<ffffffffa60e1438>] lock_acquire+0x58/0x70
>  [<ffffffffc041c08a>] ? btrfs_try_tree_write_lock+0x4a/0xb0 [btrfs]
>  [<ffffffffa69c5728>] _raw_write_lock+0x38/0x70
>  [<ffffffffc041c08a>] ? btrfs_try_tree_write_lock+0x4a/0xb0 [btrfs]
>  [<ffffffffc041c08a>] btrfs_try_tree_write_lock+0x4a/0xb0 [btrfs]
>  [<ffffffffc03f25f8>] lock_extent_buffer_for_io+0x28/0x2e0 [btrfs]
>  [<ffffffffc03fc261>] btree_write_cache_pages+0x231/0x550 [btrfs]
>  [<ffffffffc03c0cf0>] ? btree_set_page_dirty+0x20/0x20 [btrfs]
>  [<ffffffffc03c0d64>] btree_writepages+0x74/0x90 [btrfs]
>  [<ffffffffa619eb6e>] do_writepages+0x3e/0x80
>  [<ffffffffa6266ba2>] __writeback_single_inode+0x42/0x220
>  [<ffffffffa6267601>] writeback_sb_inodes+0x351/0x730
>  [<ffffffffa619aae1>] ? __wb_update_bandwidth+0x1c1/0x2b0
>  [<ffffffffa6267cd8>] wb_writeback+0x138/0x2a0
>  [<ffffffffa626854e>] wb_workfn+0x10e/0x340
>  [<ffffffffa60e099f>] ? __lock_acquire.isra.32+0x1cf/0x8c0
>  [<ffffffffa60aa05f>] process_one_work+0x24f/0x5d0
>  [<ffffffffa60a9ff0>] ? process_one_work+0x1e0/0x5d0
>  [<ffffffffa60aa433>] worker_thread+0x53/0x5b0
>  [<ffffffffa60aa3e0>] ? process_one_work+0x5d0/0x5d0
>  [<ffffffffa60b11a0>] kthread+0x120/0x140
>  [<ffffffffa60b782a>] ? finish_task_switch+0x6a/0x200
>  [<ffffffffa69c5d1f>] ret_from_fork+0x1f/0x40
>  [<ffffffffa60b1080>] ? kthread_create_on_node+0x270/0x270
> ---[ end trace 7b39395c07435bf1 ]---
>
>
>  700                         /*
>  701                          * Huh! same key, different name? Did someone trample
>  702                          * on some memory? We're most confused.
>  703                          */
>  704                         WARN_ON_ONCE(class->name != lock->name);
>
> That seems kinda scary. There was a trinity run going on at the same time,
> so this _might_ be a random scribble from something unrelated to btrfs,
> but just in case..
>
> IWBNI that code printed out both cases so I could see if this was
> corruption or two unrelated keys. I'll make it do that in case it
> happens again.


I haven't seen this one before, if you could make it happen again, that 
would be great ;)

-chris

>
> 	Dave
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>