Re: Infinite loop in sta_info_debugfs_add_work().

[Robin Holt <holt@sgi.com>]

On Tue, Oct 07, 2008 at 12:09:36AM +0200, Johannes Berg wrote:
> On Mon, 2008-10-06 at 08:30 -0500, Robin Holt wrote:
> 
> > I didn't really need to do much for the printk's in
> > ieee80211_sta_debugfs_add().  My printk's in sta_info_debugfs_add_work()
> > already told me that sta->local->debugfs.stations is NULL.  
> 
> Well yes, but I wanted to know why ieee80211_sta_debugfs_add() doesn't
> set debugfs.stations to non-NULL.
> 
> > Again, this
> > is iwl3945 only after a suspend of a few minutes followed by a resume.
> > It happens about 1/3 of the time.
> 
> Ok, I have a new suspicion: there seems to be a race condition between
> destroying a station (sta_info_destroy) which removes it from debugfs,
> and creating a new one with the same MAC address which will ask the
> workqueue to add it to debugfs. It clearly is actually possible to run
> sta_info_insert(sta2) and consequently sta_info_debugfs_add_work before
> sta_info_destroy(sta1), but when they both have the same MAC address
> then ieee80211_sta_debugfs_add has to fail.
> 
> I don't see much we can do against this, the patch I posted is
> definitely needed just in case debugfs gets a new failure mode any time
> in the future so I'll post it for inclusion, and the race condition I
> described just means that the sta2 won't be in debugfs at all...

That race seems more plausible.

On a seperate note, I got a panic with your earlier patch applied at:
IP: [<f8c669df>] :mac80211:netdev_notify+0x5f/0x90

Not sure if that is just exposed by the hangs being out of the way.  I
hand wrote that part.  Nothing else got captured in the logs :(

Thanks,
Robin