Re: apparently missing locking in if_bnx.c

[Beverly Schwartz <bschwart%bbn.com@localhost>]

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 
"my" bug.

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.

-Bev