On Thu, Mar 10, 2005 at 09:49:53PM -0500, Dave Jones wrote: > On Fri, Mar 11, 2005 at 01:40:24PM +1100, Benjamin Herrenschmidt wrote: > > > > > After it does that pci_dev_put on the from, it does another pci_dev_get > > > on 'dev', which is what my put was releasing. > > > > > > Or am I terribly confused ? > > > > Well, pci_get_class() put's the passed-in device and get's() the > > returned one. So if you run it in a loop, you should never have to > > either get or put. When you exit the loop with a valid pci_dev, though, > > you should definitely put() it after you're done with it, but this is > > something that should be done only for that specific instance and after > > you are finished with it... > > Yeah. Makes perfect sense now I've had it spelled out for me :-) > I think Linus is right though that some extra bullet-proofing in kref_put > to BUG() if it goes negative would've caught this. I wonder if anyone > else has fallen into this trap.
It can't go negative. If it hits zero, the object is freed and cleaned up. If you have slab debugging enabled, the next time you try to access this pointer, boom. So no atomic negative checks will help with kref/kobject code, sorry. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
