[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D6242AD.2090600@suse.cz>
Date: Mon, 21 Feb 2011 11:47:09 +0100
From: Jiri Slaby <jslaby@...e.cz>
To: jlbec@...lplan.org
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 02/21/2011 11:44 AM, Joel Becker wrote:
> 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?
Dunno, I just modprobe'd the configfs example from Doc dir
(configfs_example_macros).
regards,
--
js
suse labs
--
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