From: Ben Greear <[EMAIL PROTECTED]> Date: Mon, 29 Aug 2005 16:01:11 -0700
> Latest netdevice ref-count debugging patch is up. The > patch is against 2.6.13: > > http://www.candelatech.com/oss/rfcnt.patch I reviewed this, and I think the approach can be refined and made more robust. The worst part is that you do a kmalloc() on ever reference, and you shouldn't need to do that. As you have noted, a netdev refcount grab falls into two categories: 1) something->dev = dev; dev_get(dev); 2) dev_get(dev); /* some code where dev might get released but we want * to preserve the device over all the calls we're doing */ func1(); func2(); whatever(); /* Ok we're done, now can let it go for real. */ dev_put(dev); For the first case, just make a structure to hold this as the place where the device pointer gets assigned to. This would allow abstraction, get rid of the memory allocation, and for proper refcounting in fact. So you'd have something like: struct netdev; struct netdev_pointer { struct netdev *dev; #ifdef CONFIG_NETDEV_REFCNT_DEBUG struct hlist_head hash; const char *file; int line; #endif }; Then in places where we have "struct netdev *dev", you replace it with "struct netdev_pointer *__dev". You have a routine like: #define dev_set(netdev_pointer, netdev) \ do { \ netdev_pointer->dev = netdev; \ dev_get(netdev_pointer, netdev); \ netdev_pointer->file = __FILE__; \ netdev_pointer->line = __LINE__; \ } while (0) that you invoke instead of the standard: x->dev = dev; dev_get(dev); sequence. Class #2 is so transient that you can probably just use an array of dummy struct netdev_pointers that sit in struct netdev itself. Use, say, 4, and allocate them one by one until you run out. And you do the linkage into there, and thus these act as the "object" you're assigning the netdev pointer to that requires the refcount. You'll be able to store the __FILE__ and __LINE__ information quite neatly in there. Perhaps an even better idea for class #2 is to use a stack local "struct netdev_pointer", since that is the mode in which this case typically occurs, all within the same function so the function stack frame is live during the entire dummy refrence grab. This whole concept is actually quite generic, and we could thus apply it to sockets, routes, neighbour table entries, etc. And Ben you really need to get up to snuff with Linux coding standards. All of your "StudLyCaps" function names and bad tabbing hurt my eyes quite a bit and make your patches nearly impossible to review :-/ - 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
