locking anti-patterns

[Matt Macy]

The immediate solution that anyone could have made is to not call stats
collection (or any other routines that use this dubious synchronization
mechanism) from swi context:

https://github.com/mattmacy/networking/commit/421da0083e4325e242bdece18fa198
e1a96a6c67



The *_acquire_swfw code seems to be a common anti-pattern amongst drivers.
I found something very similar in bxe. My hypothesis in both cases is that
they rolled their own simply because they don't know any better.
Understanding the locking hierarchy on either Linux or FreeBSD is something
that we all have to do a better job of educating people on the periphery of
kernel development about. I have no words to describe calling DELAY(50) up
to 200 times in a row to poll for release of device resources that I would
use in a durable medium such as this.

This "lock" serializes:
i2c read/write
EEPROM access
PHY _read_/write

As an immediate addendum we want to assert that no real locks are held
while we're engaged in these shenanigans:

https://github.com/mattmacy/networking/commit/5437e3109bbd0c21a5d4bfcc3d807f
20c6ee5751

And to avoid further foot shooting we'll want to assert that these routines
are never called from swi context or one serving as an ithread. Eventually
these constructs should be replaced by sx locks and the DELAYs replaced
with sleeps.

-- 
[image: Limelight Networks] <http://www.limelight.com/>
Matt Macy - *Consultant*
 +1 650 440 8947
www.limelight.com Delivering Faster Better

Join the conversation

at Limelight Connect <https://connect.limelight.com/>
[image: Facebook] <https://connect.limelight.com/>
[image: Facebook] <https://www.facebook.com/LimelightNetworks> [image:
LinkedIn] <http://www.linkedin.com/company/limelight-networks> [image:
Twitter] <https://twitter.com/llnw>

-- 
The information in this message may be confidential.  It is intended solely 
for
the addressee(s).  If you are not the intended recipient, any disclosure,
copying or distribution of the message, or any action or omission taken by 
you
in reliance on it, is prohibited and may be unlawful.  Please immediately
contact the sender if you have received this message in error.