From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Becker Subject: Re: OOPS in configfs when doing d_delete Date: Mon, 21 Feb 2011 02:44:01 -0800 Message-ID: <20110221104359.GA18538@noexit> References: <4D623C62.8030509@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: npiggin@kernel.dk, Al Viro , linux-fsdevel@vger.kernel.org, LKML , Jiri Slaby To: Jiri Slaby Return-path: Content-Disposition: inline In-Reply-To: <4D623C62.8030509@suse.cz> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, Feb 21, 2011 at 11:20:18AM +0100, Jiri Slaby wrote: > when configfs_attach_group fails in configfs_register_subsystem: > dentry = d_alloc(configfs_sb->s_root, &name); > if (dentry) { > d_add(dentry, NULL); > > err = configfs_attach_group(sd->s_element, &group->cg_item, > dentry); > if (err) { > d_delete(dentry); > dput(dentry); > > > d_delete kills the kernel. I don't know what the actual bug is here, but > d_delete looks broken anyway: > spin_lock(&dentry->d_lock); > inode = dentry->d_inode; > isdir = S_ISDIR(inode->i_mode); <======== dereference > if (dentry->d_count == 1) { > if (inode && !spin_trylock(&inode->i_lock)) { > ^^^^^ <============= test > > It seems like a superfluous test, not a potential null dereference to > me, right? I think you're right about the superfluous test, but I need more investigation to see what's going on. Thanks for the report. What was causing attach_group() to fail? Do you know? Joel -- Life's Little Instruction Book #444 "Never underestimate the power of a kind word or deed." http://www.jlbec.org/ jlbec@evilplan.org