On Thu, Apr 18, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > > > The simple fix is to invalidate those qh->dev pointers earlier. > > > > > > ... > > > > The real fix is to put the reference counting back to the way it was and > > is supposed to be. > > Hmm, so you actually think it's a feature that driver refcounting > bugs can cause random flakiness for a couple years before > they're finally tracked down?
This is the wrong way of doing that. Poisoning is the best of catching reference counting problems. Perhaps we should modify inc_dev_use and dec_dev_use to catch the situation where a user modifies a reference count that has been set to the slab poisoning value (0xa5a5a5a5 +/- 1)? That will be a bit more proactive, but it won't always trigger in the place with the problem. > And how about having the failure mode (oops) normally finger > code that was doing the right thing, rather than the code with > the bug? That's what I call a waste of time, particularly when > we can move the failure mode closer to the root cause. > > To me this is a simple tradeoff. It's hardly simple. To be able to use the reference counting that you've changed to, my uhci_free_dev has to be very complex to be able to catch all of the corner cases. Whereas now, it's empty because of the way reference counting was intended to be used. I'd much rather choose less code over having an extra piece of code that dubiously catches bugs in other code. Linux optimizes towards the common case, and that's working code. > Of course if you have a better idea for catching such errors, I'd > like to hear it. Me, I'm just tired of having those failure modes. > Kernel garbage collection? :) No kernel garbage collection, bad idea. The problem is that your change complicates every piece of code nontrivially while only helping track down one problem. It can still trigger in the wrong place if there are too many decrements and still not trigger at all until it's too late if there are too many increments. I understand the intent, but it's the wrong way of doing it. JE _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
