Messages in this thread | | | Date | Sat, 5 Jul 2014 20:01:05 +0100 | From | Russell King - ARM Linux <> | Subject | Re: [PATCH] machine_power_off: not only local_irq_disable but also do disable preemption |
| |
On Sun, Jul 06, 2014 at 12:20:03AM +0530, pawandeep oza wrote: > Hi, > > I am referring to this version of spin lock apis. > > static inline void __raw_spin_lock(raw_spinlock_t *lock) > { > preempt_disable(); > spin_acquire(&lock->dep_map, 0, 0, _RET_IP_); > LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock); > } > > > static inline void __raw_spin_unlock(raw_spinlock_t *lock) > { > spin_release(&lock->dep_map, 1, _RET_IP_); > do_raw_spin_unlock(lock); > preempt_enable(); > } > > poweroff path runs with irqs disabled, but what is some one (valid > scenerio) try to have spin_lock and spin_unlock for its own reasons. > > spin_unlock doesn preempt_enable at the end... > which in turn does following. > > #define preempt_enable() \ > do { \ > preempt_enable_no_resched(); \ > barrier(); \ > preempt_check_resched(); \ > } while (0) > > > preempt_check_resched would check TIF_NEED_RESCHED > #define preempt_check_resched() \ > do { \ > if (unlikely(test_thread_flag(TIF_NEED_RESCHED))) \ > preempt_schedule(); \ > } while (0) > > there is a chance that just beofre we disabled irqs, somebody would have > marked the flag to current, and > later on, it might happen that, current gets replaced by the process which > tries to hold a spin_lock which has already been previosuly held by CPU1 > when > was being plugged out by smp_send_stop.
This seems to be a generic code bug - if interrupts are disabled (they are) then we should not schedule at all.
-- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.
| |