linux-kernel - Re: [PATCH] machine_power_off: not only local_irq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Sat, 5 Jul 2014 20:01:05 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	pawandeep oza <oza.contri.linux.kernel@...il.com>
Cc:	akpm@...ux-foundation.org, holt@....com, mingo@...nel.org,
	sboyd@...eaurora.org, k.khlebnikov@...sung.com,
	u.kleine-koenig@...gutronix.de,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	linux-arm-kernel@...ts.infradead.or, linux-kernel@...r.kernel.org
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/