On Mon, 2012-10-29 at 17:54 +0100, Felix Fietkau wrote: > 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. Hm yeah I must've confused it with something, I'll apply the patch. 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
