Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751920Ab3IJSZr (ORCPT ); Tue, 10 Sep 2013 14:25:47 -0400 Received: from mail-vb0-f49.google.com ([209.85.212.49]:37373 "EHLO mail-vb0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751159Ab3IJSZp (ORCPT ); Tue, 10 Sep 2013 14:25:45 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 10 Sep 2013 11:25:44 -0700 X-Google-Sender-Auth: uBAyLu0c6m_gHKH7S9mgUVLU2jI Message-ID: Subject: Re: kernel BUG at fs/dcache.c:648! with v3.11-7890-ge5c832d From: Linus Torvalds To: Josh Boyer Cc: Al Viro , Waiman Long , "Linux-Kernel@Vger. Kernel. Org" , moneta.mace@gmail.com Content-Type: multipart/mixed; boundary=001a11c1e98011673e04e60ba2f3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2546 Lines: 61 --001a11c1e98011673e04e60ba2f3 Content-Type: text/plain; charset=UTF-8 On Tue, Sep 10, 2013 at 10:47 AM, Linus Torvalds wrote: > > But yes, e5c832d is obviously the "fixed" kernel. Let me think about this. Ok, I think I found it. I missed that "terminate_walk()" for the RCU case does this: nd->flags &= ~LOOKUP_RCU; if (!(nd->flags & LOOKUP_ROOT)) nd->root.mnt = NULL; unlock_rcu_walk(); and my unlazy_walk() essentially terminated the walk _without_ clearing that nd->root.mnt thing (it did clear the LOOKUP_RCU bit and unlock_rcy_walk(). So then later, we'd end up doing an extra path_put(). Explaining a zero d_lockref.count. The whole damn root.mnt behavior with !LOOKUP_ROOT is a mystery and needs more comments. But the attached trivial patch should do the missing portion of terminate_walk(). Al, can you walk us through the rules for what "root.mnt == NULL" really means? It's basically used as a flag for whether we've gotten the root pointer or not. But it's pretty damn esoteric. Now I'm starting to wonder how come _I_ never saw any issues. Maybe it ends up underflowing so quickly that most people just see a big negative number.. Patch is entirely untested. Not that my testing apparently has been much good. Moneta, are you comfortable compiling a test-kernel, or does this need to become a rawhide package? Linus --001a11c1e98011673e04e60ba2f3 Content-Type: application/octet-stream; name="patch.diff" Content-Disposition: attachment; filename="patch.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hlfg5pd50 IGZzL25hbWVpLmMgfCA1ICsrKystCiAxIGZpbGUgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspLCAx IGRlbGV0aW9uKC0pCgpkaWZmIC0tZ2l0IGEvZnMvbmFtZWkuYyBiL2ZzL25hbWVpLmMKaW5kZXgg NTZlNGY0ZDUzN2QwLi41ZTZhYWFkYzFkY2QgMTAwNjQ0Ci0tLSBhL2ZzL25hbWVpLmMKKysrIGIv ZnMvbmFtZWkuYwpAQCAtNTc0LDkgKzU3NCwxMiBAQCB1bmxvY2tfYW5kX2Ryb3BfZGVudHJ5Ogog ZHJvcF9kZW50cnk6CiAJdW5sb2NrX3JjdV93YWxrKCk7CiAJZHB1dChkZW50cnkpOwotCXJldHVy biAtRUNISUxEOworCWdvdG8gZHJvcF9yb290X21udDsKIG91dDoKIAl1bmxvY2tfcmN1X3dhbGso KTsKK2Ryb3Bfcm9vdF9tbnQ6CisJaWYgKCEobmQtPmZsYWdzICYgTE9PS1VQX1JPT1QpKQorCQlu ZC0+cm9vdC5tbnQgPSBOVUxMOwogCXJldHVybiAtRUNISUxEOwogfQogCg== --001a11c1e98011673e04e60ba2f3-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/