[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110221104359.GA18538@noexit>
Date: Mon, 21 Feb 2011 02:44:01 -0800
From: Joel Becker <jlbec@...lplan.org>
To: Jiri Slaby <jslaby@...e.cz>
Cc: npiggin@...nel.dk, Al Viro <viro@...iv.linux.org.uk>,
linux-fsdevel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
Jiri Slaby <jirislaby@...il.com>
Subject: Re: OOPS in configfs when doing d_delete
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@...lplan.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists