Re: [PATCH] machine_power_off: not only local_irq_disable but also do disable preemption

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

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.