RE: [PATCH v2 net] bnx2x: Fix statistics locking scheme

[Yuval Mintz <Yuval.Mintz@qlogic.com>]

> > +int bnx2x_stats_safe_exec(struct bnx2x *bp,
> > +			  void (func_to_exec)(void *cookie),
> > +			  void *cookie)
>  ...
> > +	if (bp->stats_pending) {
> > +		BNX2X_ERR("Failed to wait for stats pending to clear\n");
> > +		return -EBUSY;
> 
> Buggy, this returns with the stats_lock still held.

Ouch; You're right - I'll fix it.

> 
> In my humble opinion, you are putting very little care and effort into this bug fix.

Well, we've put quite a bit in the logic behind it; But you're probably right
About the effort put into v2.

> Also I disagree with your timeout logic.
> 
> I suspect that the real reason these timeouts are present, is that the locking
> hierarchy is uncertain.
> 
> Nothing really should create the situation those trylocks seem to be dealing
> with.

Actually, you're probably right in the assumption - I have a feeling that due to
the races in the previous implementation, there was lack of confidence in the
general process.
According to my current analysis there shouldn't be any real need for the limit
on time, since there are no limitless loops taking place while the locks are being
held [at most, HW/FW is asserted and nothing happens; But it still should take
only a couple of mili-seconds].
The only reason I've left this was to leave the implementation close as I can to
original [which used that locking mechanism] given that it's intended to `net'.
Do you prefer I simply switch over into using a regular mutex?