Received: by 10.213.65.68 with SMTP id h4csp2764876imn; Mon, 2 Apr 2018 13:39:11 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/EkvdU0dhuxm4LKJqUWjXNhNcKebiSbMqdCF0wMqIpcYB/50NTOVV0vvYZBFwg1EY6n4Ul X-Received: by 10.99.121.131 with SMTP id u125mr7352194pgc.48.1522701551858; Mon, 02 Apr 2018 13:39:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522701551; cv=none; d=google.com; s=arc-20160816; b=XdXq3Vce9/8rI4n/UOHVbXLOGBxQ8kV2j2NqVpMd3qaYItiMB+dRV414dstivpYfPy 2H4fjZOe72aC4Sgcn/F8Eswj4/RUnogQxwJt1i/eshzBxsjoRjV6HmZ9RtK3WfQ+S+0b ho+4tqdJKzeSjfJWjlRG4XtEAPATsxvxfNhxb6uhVMxX/4XuqleChL6deFAS4f8vINDg QnIBi/w4coSHAts+plz1nVEViz45yrdceZ2xWevfX6Bt44gfYqaUP/gsB6YDH7e7EzbQ 8hjci0Eabng99f0zwSWmtJa3tWGqYeAh6R2b0/VdkIIZNT1YSEsvTm1Jv6Uwa3qR+NE2 JPsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=VwsZ2FfAiY+dzYGNxIUXEVNusT/3x9eGlLBj5GTIOuI=; b=nOGmd22jqSCSRiUmqOaczxm27NdTfZ3nBqiz5p4G6415QS/3RhqcfLu56DkhrebsII mN7UbOPMsXB6c0fccb2Lp4W6CpsqKwrDqeG/uJMidotusXnW6stWXqB8hHhEV2kKwxeH oogbvj/kd9GJ37tpHkFRr1BQn4sftS1YGURqANE2lOG61LI3x9KJf1CsUxYi6DhTvU4X Hehg9sEqusFXdOBJkSBLGvB/xT8eKCKb5xI4Ks/Yuxdk90G++Co8jVsZ0u6sQiFTSXZ9 JR5JeW+jsqJQjEIAeobDTRD9vsBvjUEElzFZWGzML3FW1xS9IMxBX++GfXn8PO4+Prbx 8ZNg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m14si725847pgt.287.2018.04.02.13.38.57; Mon, 02 Apr 2018 13:39:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932480AbeDBUht (ORCPT + 99 others); Mon, 2 Apr 2018 16:37:49 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:37034 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756678AbeDBUhs (ORCPT ); Mon, 2 Apr 2018 16:37:48 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1f36D4-0006ng-6O; Mon, 02 Apr 2018 20:37:46 +0000 Date: Mon, 2 Apr 2018 21:37:46 +0100 From: Al Viro To: Eric Biggers Cc: syzbot , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com, linux-nfs@vger.kernel.org Subject: Re: BUG: corrupted list in __dentry_kill Message-ID: <20180402203745.GE30522@ZenIV.linux.org.uk> References: <001a11447acaa9eec40568bd5438@google.com> <20180401033519.GZ30522@ZenIV.linux.org.uk> <20180401200531.GA30522@ZenIV.linux.org.uk> <20180401210508.GA743@sol.localdomain> <20180401214854.GB743@sol.localdomain> <20180402064437.GB30522@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180402064437.GB30522@ZenIV.linux.org.uk> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 02, 2018 at 07:44:37AM +0100, Al Viro wrote: > On Sun, Apr 01, 2018 at 02:48:54PM -0700, Eric Biggers wrote: > > [+Cc linux-nfs] > > > > > > [ 42.965515] net/sunrpc/rpc_pipe.c: __rpc_create_common failed to allocate inode for dentry blocklayout > > > [ 42.967234] net/sunrpc/rpc_pipe.c: rpc_mkpipe_dentry() failed to create pipe nfs/blocklayout (errno = -12) > > AFAICS, there's nothing to zero nn->bl_device_pipe->dentry after > nfs4blocklayout_unregister_sb(), is there? If nothing else, what's > going to happen after mount/umount/mount with failing > nfs4blocklayout_register_sb()? AFAICS, we'll have stale pointer to > dentry sitting in nn->bl_device_pipe->dentry, and call rpc_unlink() > on it while cleaning up after the failing mount. > > I don't think that's all there is to it, but it does smell like > a bug. That's not all. Making nfs4blocklayout_register_sb() immediately fail (without doing anything) leads to that oops on the very first attempt to mount rpc_pipefs. Matter of fact, rpc_gssd_dummy_depopulate() is garbage. I don't know how it had been tested, but it will do an extra dput() of gssd_dentry whenever it's called. _Any_ failure that sends us to err_depopulate: (== any failure in rpc_pipefs_notifier_list callbacks) means an oops there on attempt to dput() an already freed dentry. Hell, turn that if (err) goto?err_depopulate; into if (err || !strcmp(current->comm, "bugger")) goto err_depopulate; cp /bin/mount /root/bugger, then boot with init=/bin/sh and cd /root; ./bugger -t rpc_pipefs none /mnt will trigger just that.