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.
Dave
