From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:34485 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753461AbcIIPTU (ORCPT ); Fri, 9 Sep 2016 11:19:20 -0400 Subject: Re: lockdep warning in btrfs in 4.8-rc3 To: Dave Jones , Christian Borntraeger , LKML , linux-btrfs References: <20160826233624.jao5mztbxhjikm7e@floor.thefacebook.com> <6a3eed93-fb4d-817a-6a59-7e7f91c8ea6d@de.ibm.com> <624b2c3a-5030-3f7f-70d6-4507308d785b@de.ibm.com> <20160909005055.n6be4cvwvi7byk3j@codemonkey.org.uk> From: Chris Mason Message-ID: <03c4ab5c-11bf-9bf5-dd6f-94e913e6efb1@fb.com> Date: Fri, 9 Sep 2016 11:19:03 -0400 MIME-Version: 1.0 In-Reply-To: <20160909005055.n6be4cvwvi7byk3j@codemonkey.org.uk> Content-Type: text/plain; charset="windows-1252"; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: 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: > [] dump_stack+0x6c/0x9b > [] ? register_lock_class+0x33f/0x510 > [] __warn+0x110/0x130 > [] warn_slowpath_null+0x2c/0x40 > [] register_lock_class+0x33f/0x510 > [] ? bio_add_page+0x7e/0x120 > [] __lock_acquire.isra.32+0x5b/0x8c0 > [] lock_acquire+0x58/0x70 > [] ? btrfs_try_tree_write_lock+0x4a/0xb0 [btrfs] > [] _raw_write_lock+0x38/0x70 > [] ? btrfs_try_tree_write_lock+0x4a/0xb0 [btrfs] > [] btrfs_try_tree_write_lock+0x4a/0xb0 [btrfs] > [] lock_extent_buffer_for_io+0x28/0x2e0 [btrfs] > [] btree_write_cache_pages+0x231/0x550 [btrfs] > [] ? btree_set_page_dirty+0x20/0x20 [btrfs] > [] btree_writepages+0x74/0x90 [btrfs] > [] do_writepages+0x3e/0x80 > [] __writeback_single_inode+0x42/0x220 > [] writeback_sb_inodes+0x351/0x730 > [] ? __wb_update_bandwidth+0x1c1/0x2b0 > [] wb_writeback+0x138/0x2a0 > [] wb_workfn+0x10e/0x340 > [] ? __lock_acquire.isra.32+0x1cf/0x8c0 > [] process_one_work+0x24f/0x5d0 > [] ? process_one_work+0x1e0/0x5d0 > [] worker_thread+0x53/0x5b0 > [] ? process_one_work+0x5d0/0x5d0 > [] kthread+0x120/0x140 > [] ? finish_task_switch+0x6a/0x200 > [] ret_from_fork+0x1f/0x40 > [] ? 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 >