On 2012-10-29 5:26 PM, Johannes Berg wrote: > On Mon, 2012-10-29 at 09:17 -0700, Ben Greear wrote: > >> >> + spin_lock_bh(&rdev->beacon_registrations_lock); >> > ... >> >> + spin_unlock_bh(&rdev->beacon_registrations_lock); >> > >> > I have a feeling this is incorrect, this is called with BHs disabled, so >> > if we disable/enable BHs here we end up with BHs enabled even if the >> > caller wanted them disabled, no? >> > >> > So I suppose unless we need to be able to call this from hard interrupt >> > in some driver (unlikely) we should add a change like this: >> >> I get confused with the various types of spin-locks, >> and I just copied this code from the mgt frames logic. > > Uh, that looks like a bug there as well then? As far as I know, local_bh_enable/local_bh_disable (which are used by spin_lock_bh) are re-entrant. Using them from a BH-disabled context is safe. All I can find with a few simple google searches confirms this. - Felix -- 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