On Mon, 2011-02-14 at 14:35 -0800, Nathaniel Smith wrote:

quoted

Right -- but it makes the TX path quite a bit more expensive on some
architectures. Why is this necessary? There should be locking in most
places already, and where not it should be easy to move this under the
existing lock.

Yes, I suspect we could use the priv->lock for this purpose (at the
expense of adding a lock/unlock on the TX notification path), but I'd
like some confirmation from someone more familiar with the code before
trying. high_mark is read from all over the place, and was previously
read-only, so it really needs someone who understands this driver's
locking "big picture" to check correctness.

Actually, it doesn't really matter. Linux assumes that reads and writes
to "unsigned long" are always atomic against each other (i.e. you get
either the old or the new value) and that's all you care about here --
this never needs anything like atomic_inc/dec etc.

johannes