On Mon, 2011-02-14 at 14:35 -0800, Nathaniel Smith wrote: > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
