Patrick McHardy wrote: >>Its harmless since its a read lock, which can be nested. I actually >>don't see any need for qdisc_tree_lock at all, all changes and all >>walking is done under the RTNL, which is why I've removed it in >>my (upcoming) patches. I suggest to leave it as is for now so I >>don't need to change the __qdisc_lookup back to qdisc_lookup in >>2.6.22. > > > > Alexey just explained to me why we do need qdisc_tree_lock in private > mail. While dumping only the first skb is filled under the RTNL, > while filling further skbs we don't hold the RTNL anymore. So I will > probably have to drop that patch.
What we could do is replace the netlink cb_lock spinlock by a user-supplied mutex (supplied to netlink_kernel_create, rtnl_mutex in this case). That would put the entire dump under the rtnl and allow us to get rid of qdisc_tree_lock and avoid the need to take dev_base_lock during qdisc dumping. Same in other spots like rtnl_dump_ifinfo, inet_dump_ifaddr, ... What do you think? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
