From: Tejun Heo <htejun@gmail.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Gabor Gombas <gombasg@sztaki.hu>, Greg KH <greg@kroah.com>,
linux-kernel@vger.kernel.org, ebiederm@xmission.com,
bluez-devel@lists.sf.net
Subject: Re: [Bluez-devel] Oops involving RFCOMM and sysfs
Date: Mon, 07 Jan 2008 11:37:45 +0900 [thread overview]
Message-ID: <47819079.3000606@gmail.com> (raw)
In-Reply-To: <478037F8.8020103@gmail.com>
Hello,
Tejun Heo wrote:
> Al Viro wrote:
>> On Sat, Jan 05, 2008 at 11:30:25PM +0900, Tejun Heo wrote:
>>>> Assuming that this is what we get, everything looks explainable - we
>>>> have sysfs_rename_dir() calling sysfs_get_dentry() while the parent
>>>> gets evicted. We don't have any exclusion, so while we are playing
>>>> silly buggers with lookups in sysfs_get_dentry() we have parent become
>>>> negative; the rest is obvious...
>>> That part of code is walking down the sysfs tree from the s_root of
>>> sysfs hierarchy and on each step parent is held using dget() while being
>>> referenced, so I don't think they can turn negative there.
>> Turn? Just what stops you from getting a negative (and unhashed) from
>> lookup_one_noperm() and on the next iteration being buggered on mutex_lock()?
>
> Right, I haven't thought about that. When sysfs_get_dentry() is called,
> @sd is always valid so unless there was existing negative dentry, lookup
> is guaranteed to return positive dentry, but by populating dcache with
> negative dentry before a node is created, things can go wrong. I don't
> think that's what's going on here tho. If that was the case, the
> while() loop looking up the next sd to lookup (@cur) should have blown
> up as negative dentry will have NULL d_fsdata which doesn't match any sd.
>
> I guess what's needed here is d_revalidate() as other distributed
> filesystems do. I'll test whether this can be actually triggered and
> prepare a fix. Thanks a lot for pointing out the problem.
This can't happen because lookup of non-existent entry doesn't create a
negative dentry. The new dentry is never hashed and killed after lookup
failure, the above scenario can't happen.
That said, the mechanism is a bit too fragile. sysfs currently ensures
that dentry/inode point to the associated sysfs_dirent. This is mainly
remanent of conversion from previous VFS based implementation. I think
the right thing to do here is to make sysfs behave like other proper
distributed filesystems using d_revalidate.
Thanks.
--
tejun
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <htejun@gmail.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Gabor Gombas <gombasg@sztaki.hu>,
Dave Young <hidave.darkstar@gmail.com>,
linux-kernel@vger.kernel.org, bluez-devel@lists.sourceforge.net,
Greg KH <greg@kroah.com>,
ebiederm@xmission.com
Subject: Re: [Bluez-devel] Oops involving RFCOMM and sysfs
Date: Mon, 07 Jan 2008 11:37:45 +0900 [thread overview]
Message-ID: <47819079.3000606@gmail.com> (raw)
In-Reply-To: <478037F8.8020103@gmail.com>
Hello,
Tejun Heo wrote:
> Al Viro wrote:
>> On Sat, Jan 05, 2008 at 11:30:25PM +0900, Tejun Heo wrote:
>>>> Assuming that this is what we get, everything looks explainable - we
>>>> have sysfs_rename_dir() calling sysfs_get_dentry() while the parent
>>>> gets evicted. We don't have any exclusion, so while we are playing
>>>> silly buggers with lookups in sysfs_get_dentry() we have parent become
>>>> negative; the rest is obvious...
>>> That part of code is walking down the sysfs tree from the s_root of
>>> sysfs hierarchy and on each step parent is held using dget() while being
>>> referenced, so I don't think they can turn negative there.
>> Turn? Just what stops you from getting a negative (and unhashed) from
>> lookup_one_noperm() and on the next iteration being buggered on mutex_lock()?
>
> Right, I haven't thought about that. When sysfs_get_dentry() is called,
> @sd is always valid so unless there was existing negative dentry, lookup
> is guaranteed to return positive dentry, but by populating dcache with
> negative dentry before a node is created, things can go wrong. I don't
> think that's what's going on here tho. If that was the case, the
> while() loop looking up the next sd to lookup (@cur) should have blown
> up as negative dentry will have NULL d_fsdata which doesn't match any sd.
>
> I guess what's needed here is d_revalidate() as other distributed
> filesystems do. I'll test whether this can be actually triggered and
> prepare a fix. Thanks a lot for pointing out the problem.
This can't happen because lookup of non-existent entry doesn't create a
negative dentry. The new dentry is never hashed and killed after lookup
failure, the above scenario can't happen.
That said, the mechanism is a bit too fragile. sysfs currently ensures
that dentry/inode point to the associated sysfs_dirent. This is mainly
remanent of conversion from previous VFS based implementation. I think
the right thing to do here is to make sysfs behave like other proper
distributed filesystems using d_revalidate.
Thanks.
--
tejun
next prev parent reply other threads:[~2008-01-07 2:37 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-28 17:32 [Bluez-devel] Oops involving RFCOMM and sysfs Gabor Gombas
2007-12-28 17:32 ` Gabor Gombas
2007-12-29 8:07 ` [Bluez-devel] " Dave Young
2007-12-29 8:07 ` Dave Young
2008-01-02 14:48 ` Gabor Gombas
2008-01-02 14:48 ` Gabor Gombas
2008-01-02 15:16 ` Gabor Gombas
2008-01-03 13:16 ` Gabor Gombas
2008-01-04 1:05 ` Dave Young
2008-01-04 1:05 ` Dave Young
2008-01-07 8:07 ` Tejun Heo
2008-01-07 8:07 ` Tejun Heo
2008-01-07 14:10 ` Gabor Gombas
2008-01-07 14:10 ` Gabor Gombas
2008-01-05 7:50 ` Al Viro
2008-01-05 7:50 ` Al Viro
2008-01-05 14:30 ` Tejun Heo
2008-01-05 14:30 ` Tejun Heo
2008-01-05 19:45 ` Al Viro
2008-01-05 19:45 ` Al Viro
2008-01-06 2:07 ` Tejun Heo
2008-01-06 2:07 ` Tejun Heo
2008-01-06 2:18 ` Al Viro
2008-01-06 2:18 ` Al Viro
2008-01-06 2:54 ` Tejun Heo
2008-01-06 2:54 ` Tejun Heo
2008-01-06 3:35 ` Al Viro
2008-01-06 3:35 ` Al Viro
2008-01-06 3:54 ` Tejun Heo
2008-01-07 2:37 ` Tejun Heo [this message]
2008-01-07 2:37 ` Tejun Heo
2008-01-07 8:21 ` Eric W. Biederman
2008-01-07 8:21 ` Eric W. Biederman
2008-01-07 9:17 ` Tejun Heo
2008-01-07 9:17 ` Tejun Heo
2008-01-07 9:18 ` Tejun Heo
2008-01-07 9:18 ` Tejun Heo
2008-01-07 9:22 ` Al Viro
2008-01-07 9:22 ` Al Viro
2008-01-07 10:33 ` Eric W. Biederman
2008-01-07 10:33 ` Eric W. Biederman
2008-01-07 14:13 ` Gabor Gombas
2008-01-07 14:13 ` Gabor Gombas
2008-01-07 15:24 ` Tejun Heo
2008-01-07 15:24 ` Tejun Heo
2008-01-07 21:00 ` Gabor Gombas
2008-01-07 21:00 ` Gabor Gombas
2008-01-08 9:42 ` Tejun Heo
2008-01-08 13:32 ` Gabor Gombas
2008-01-08 13:32 ` Gabor Gombas
2008-01-09 9:16 ` Tejun Heo
2008-01-09 9:16 ` Tejun Heo
2008-01-09 15:57 ` Cornelia Huck
2008-01-10 1:11 ` Dave Young
2008-01-10 1:11 ` Dave Young
2008-01-11 23:09 ` Gabor Gombas
2008-01-11 23:09 ` Gabor Gombas
2008-01-14 7:05 ` Dave Young
2008-01-14 12:52 ` Cornelia Huck
2008-01-15 1:57 ` Dave Young
2008-01-16 1:02 ` Dave Young
2008-01-16 23:06 ` Gabor Gombas
2008-01-17 7:24 ` Dave Young
2008-01-17 8:15 ` Dave Young
2008-01-17 11:42 ` Cornelia Huck
2008-01-18 3:37 ` Dave Young
2008-01-18 9:19 ` Cornelia Huck
2008-01-18 10:23 ` Cornelia Huck
2008-01-18 10:34 ` Dave Young
2008-01-18 11:26 ` Cornelia Huck
2008-01-21 3:15 ` Dave Young
2008-01-21 15:09 ` [Patch] Driver core: Cleanup get_device_parent() in device_add() and device_move() Cornelia Huck
2008-01-10 10:15 ` [Bluez-devel] Oops involving RFCOMM and sysfs Gabor Gombas
2008-01-10 10:15 ` Gabor Gombas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47819079.3000606@gmail.com \
--to=htejun@gmail.com \
--cc=bluez-devel@lists.sf.net \
--cc=bluez-devel@lists.sourceforge.net \
--cc=ebiederm@xmission.com \
--cc=gombasg@sztaki.hu \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.