On Wed, Aug 6, 2008 at 9:51 AM, Dave Young [off-list ref] wrote:

On Tue, Aug 5, 2008 at 8:24 PM, Bob Copeland [off-list ref] wrote:

quoted

On Tue, Aug 05, 2008 at 09:29:26AM +0800, Dave Young wrote:

quoted

With the patch I cann't reproduce the bug with 27-rc1 now.

quoted

 [<c02375a6>] ? debugfs_create_file+0x46/0x210
 [<c02375a6>] ? debugfs_create_file+0x46/0x210
 [<c02375a6>] debugfs_create_file+0x46/0x210
 [<c02377f1>] debugfs_create_dir+0x21/0x30
 [<f8901f6d>] ieee80211_sta_debugfs_add+0x2d/0x150 [mac80211]
 [<f88eba89>] sta_info_debugfs_add_work+0x89/0x130 [mac80211]
 [<f890a170>] ? rate_control_pid_add_sta_debugfs+0x0/0x30 [mac80211]

I wonder if there were two separate problems here.  I looked into
this with some detail yesterday and agree with Johannes that the above
trace is on locking the parent directory's i_mutex, but I too couldn't
see any problems with sta_info_debugfs_add_work.  Other stuff could also
modify the directory with or without rtnl_lock, but not in a way that
to my untrained eyes would lead to deadlock.

Yes,. I think so. It's the original bug for me, while testing I found
the mutex deadlock problem.

But this week I will have no time to trace it. so if I have time I
will keep tracing the problem

Additional info,

With the mutex fix patch, in 2.6.27-rc1 I seems can not reproduce the
debugfs_add bug, (maybe need more test)

But with 2.6.26, the bug can be reproduced. (The mutex fix patch need
not to be applied because there's no such deadlock bug)

quoted

Or is the trace just wrong?

--
Bob Copeland %% www.bobcopeland.com

--
Regards
dave

-- 
Regards
dave