Le lundi 12 décembre 2011 à 19:46 +0200, Daniel Baluta a écrit : > On Mon, Dec 12, 2011 at 7:33 PM, Greg KH <greg@xxxxxxxxx> wrote: > > On Mon, Dec 12, 2011 at 06:42:59PM +0200, Daniel Baluta wrote: > >> On Mon, Dec 12, 2011 at 5:41 PM, Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote: > >> > Le lundi 12 décembre 2011 ŕ 17:39 +0200, Daniel Baluta a écrit : > >> > > >> >> Ok, for the moment it seems to be a bad idea. But my intention is > >> >> to integrate kref to networking code, and then to write a general > >> >> debugging tool for refs. > >> >> > >> >> Tracking down reference count problems is hard, and this tool can > >> >> really help everyone. > >> > > >> > I dont think kref will help you that much, because its used everywhere. > >> > > >> > Adding a general debugging tool will provide too much noise. > >> > > >> > Instead, we (network dev) add debugging points where we want. > >> > >> Yes, but you have to do this each time you start debugging, for a > >> particular referenced counted object. > >> > >> We must find a clever solution to avoid the noise. (e.g use > >> /proc, /sysfs, /debugfs options to trigger dumping info for > >> some/all objects with a certain state). > > > > Then use the dynamic debug infrastructure, which is there to help you > > try to handle this type of debugging on-the-fly. > > > > But again, it's not a kref issue, sorry. > > I see. Thanks. > > One last remark: Should we encourage people > to use kref implementation, instead of making > their own ? > > What are the chances of accepting changes with > respect to this? > > Just a few examples: > > neighbour.h > 295:#define neigh_hold(n) atomic_inc(&(n)->refcnt) > > addrconf.h > 219:static inline void in6_dev_hold(struct inet6_dev *idev) > I dont know how to say this Daniel. I dont think kref added layer is helping this. Just say no. Since we convert about all network stack to RCU, we need much better api than kref is offering. (atomic_..._not_zero for example) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html