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
| ||
|
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/
Powered by blists - more mailing lists