> I did.. I added another set of functions for default management key and > did not remember to call the removal function from > ieee80211_free_keys(). However, adding that call did not change > anything. Ok. > It looks like we end up trying to remove the netdev directory in debugfs > before removing the default key symlinks. Consequently, debugfs_remove() > fails since there is still a file in the directory. This is what happens > when removing the monitor interface: > > cfg.c: ieee80211_del_iface() -> > iface.c: ieee80211_if_remove() -> > iface.c: __ieee80211_if_del() -> > debugfs_netdev.c: ieee80211_debugfs_remove_netdev() > [too early; symlink still there] > unregister_netdevice(dev) -> [dev->uninit] > iface.c: ieee80211_if_reinit() -> > key.c: ieee80211_free_keys() -> > debugfs_key.c: ieee80211_debugfs_key_remove_default() > > > Any idea how to fix this? Hmm, no, no idea at all. To be honest, I don't fully understand interface lifetime rules and I think many of those functions are probably misnamed. I.e. why is the _reinit function assigned to the ->uninit callback? Much of that either comes from the original Devicescape code or what Jiri did to it, and I never bothered to clean it up. > Why is ieee80211_debugfs_remove_netdev() call > in __ieee80211_if_del()? I don't really know. Probably because that's where Jiri had the sysfs code I converted to debugfs ;) > Could it be moved into ieee80211_if_reinit(), > so that it would happen only after the ieee80211_free_keys() call? That's well possible, I guess you'd have to try. > Since > ieee80211_if_reinit() is called from other places, too, it might be > cleaner to define a new dev->uninit function that is a wrapper for call > to ieee80211_if_reinit() followed by call to > ieee80211_debugfs_remove_netdev().. However, since ieee80211_if_reinit() > calls ieee80211_if_sdata_deinit(), it might be necessary to call > ieee80211_debugfs_remove_netdev() before this call (or from it?); I did > not yet look into details of what would be the required order for these. I really don't know either. If you feel motivated to clean up the interface handling I'd appreciate it. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
