Michael Buesch wrote:
In general, no. But, for some sysfs attrs it is sufficient to only take the mutex, because: * We don't access hardware. * We don't modify this data in a spinlock-only critical section. Yes, I know that having two locks does not really fit the "lock data, not code" model. But it's well defined in bcm43xx, so I think we can live with it. (and we must live with it, if we want to have preemptible periodic work. And we _want_). It's defined by the following rules: 1) Always take both, mutex and lock. 2) There are only two places where we can't take the mutex, but only the spinlock. IRQ and TX paths. (Yes, I know that there are still exceptions to 2. At least in dscape. The softmac port should be OK. These are bugs, I am aware of them and will fix it) So these two rules lead to the following rule: * Code where we only take the mutex can race against the TX and IRQ paths. Now we come back to the sysfs problem above. If the data, we access in this sysfs code, is not touched in either TX or IRQ path we don't need to take the spinlock. Yes, it's a little bit black magic. So if you aren't sure, always take both locks.
Thanks for the clarification. Larry - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
