Am 26.11.2014 um 17:19 schrieb Michael S. Tsirkin: > On Wed, Nov 26, 2014 at 05:02:23PM +0100, David Hildenbrand wrote: >>>> This is what happened on our side (very recent kernel): >>>> >>>> spin_lock(&lock) >>>> copy_to_user(...) >>>> spin_unlock(&lock) >>> >>> That's a deadlock even without copy_to_user - it's >>> enough for the thread to be preempted and another one >>> to try taking the lock. >>> >>> >>>> 1. s390 locks/unlocks a spin lock with a compare and swap, using the _cpu id_ >>>> as "old value" >>>> 2. we slept during copy_to_user() >>>> 3. the thread got scheduled onto another cpu >>>> 4. spin_unlock failed as the _cpu id_ didn't match (another cpu that locked >>>> the spinlock tried to unlocked it). >>>> 5. lock remained locked -> deadlock >>>> >>>> Christian came up with the following explanation: >>>> Without preemption, spin_lock() will not touch the preempt counter. >>>> disable_pfault() will always touch it. >>>> >>>> Therefore, with preemption disabled, copy_to_user() has no idea that it is >>>> running in atomic context - and will therefore try to sleep. >>>> >>>> So copy_to_user() will on s390: >>>> 1. run "as atomic" while spin_lock() with preemption enabled. >>>> 2. run "as not atomic" while spin_lock() with preemption disabled. >>>> 3. run "as atomic" while pagefault_disabled() with preemption enabled or >>>> disabled. >>>> 4. run "as not atomic" when really not atomic. >> >> should have been more clear at that point: >> preemption enabled == kernel compiled with preemption support >> preemption disabled == kernel compiled without preemption support >> >>>> >>>> And exactly nr 2. is the thing that produced the deadlock in our scenario and >>>> the reason why I want a might_sleep() :) >>> >>> IMHO it's not copy to user that causes the problem. >>> It's the misuse of spinlocks with preemption on. >> >> As I said, preemption was off. > > off -> disabled at compile time? > > But the code is broken for people that do enable it. [...] > You should normally disable preemption if you take > spinlocks. Your are telling that any sequence of spin_lock ... spin_unlock is broken with CONFIG_PREEMPT? Michael, that is bullshit. spin_lock will take care of CONFIG_PREEMPT just fine. Only sequences like spin_lock ... schedule ... spin_unlock are broken. But as I said. That is not the problem that we are discussing here. Christian -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
