[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: apparently missing locking in if_bnx.c
On Mar 7, 2012, at 3:33 AM, Martin Husemann wrote:
> On Tue, Mar 06, 2012 at 07:37:44PM -0500, Beverly Schwartz wrote:
>> Lockdebug, so far, has been entirely unhelpful, even detrimental.
> Lockdebug is very usefull to catch a lot of locking errors and provide
> great diagnostics. However, it has a very severe performance impact. So
> if the problem you are hunting is not one of the lock-misuses lockdebug
> can detect (like in the bnx case), it will not help. Worse, due to the
> different timing it will change chances for all races involved, which
> might even hide bugs.
I understand that lockdebug changes timing and can impact performance and that
my bug may "disappear" because of that. What I found really difficult was that
for my bug, lockdebug consistently caused a freeze up. Not a panic. Not a
crash. An indiscriminate freeze. And it happened quickly and consistently.
That sent me down a completely wrong path of inquiry, taking me further from
Now that we have a fix to "my" bug, lockdebug is affecting performance, as
expected, but not causing additional problems.
So, in my mind, lockdebug was an impediment to my work. Only after I disabled
lockdebug did I make progress. While lockdebug may "hide" a bug because of
timing changes, it should not create completely new problems and symptoms that
are more difficult to work with than the original bug.
Main Index |
Thread Index |