From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Sasha Levin <sasha.levin@oracle.com>
Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
peterz@infradead.org, torvalds@linux-foundation.org,
konrad.wilk@oracle.com, pbonzini@redhat.com,
paulmck@linux.vnet.ibm.com, waiman.long@hp.com, davej@redhat.com,
oleg@redhat.com, x86@kernel.org, jeremy@goop.org,
paul.gortmaker@windriver.com, ak@linux.intel.com,
jasowang@redhat.com, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
xen-devel@lists.xenproject.org, riel@redhat.com,
borntraeger@de.ibm.com, akpm@linux-foundation.org,
a.ryabinin@samsung.com
Subject: Re: [PATCH] x86 spinlock: Fix memory corruption on completing completions
Date: Sun, 08 Feb 2015 23:27:56 +0530 [thread overview]
Message-ID: <54D7A3A4.1030609@linux.vnet.ibm.com> (raw)
In-Reply-To: <54D50E84.2060703@oracle.com>
On 02/07/2015 12:27 AM, Sasha Levin wrote:
> On 02/06/2015 09:49 AM, Raghavendra K T wrote:
>> Paravirt spinlock clears slowpath flag after doing unlock.
>> As explained by Linus currently it does:
>> prev = *lock;
>> add_smp(&lock->tickets.head, TICKET_LOCK_INC);
>>
>> /* add_smp() is a full mb() */
>>
>> if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG))
>> __ticket_unlock_slowpath(lock, prev);
>>
>>
>> which is *exactly* the kind of things you cannot do with spinlocks,
>> because after you've done the "add_smp()" and released the spinlock
>> for the fast-path, you can't access the spinlock any more. Exactly
>> because a fast-path lock might come in, and release the whole data
>> structure.
>>
>> Linus suggested that we should not do any writes to lock after unlock(),
>> and we can move slowpath clearing to fastpath lock.
>>
>> However it brings additional case to be handled, viz., slowpath still
>> could be set when somebody does arch_trylock. Handle that too by ignoring
>> slowpath flag during lock availability check.
>>
>> Reported-by: Sasha Levin <sasha.levin@oracle.com>
>> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
>> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
>
> With this patch, my VMs lock up quickly after boot with:
Tried to reproduce the hang myself, and there seems to be still a
barrier (or logic I miss).
Looking closely below, unlock_kick got missed though we see
that SLOWPATH_FLAG is still set:
/me goes back to look closely
(gdb) bt
#0 native_halt () at ./arch/x86/include/asm/irqflags.h:55
#1 0xffffffff81037c27 in halt () at ./arch/x86/include/asm/paravirt.h:116
#2 kvm_lock_spinning (lock=0xffff88023ffe8240, want=52504) at
arch/x86/kernel/kvm.c:786
#3 0xffffffff81037251 in __raw_callee_save_kvm_lock_spinning ()
#4 0xffff88023fc0edb0 in ?? ()
#5 0x0000000000000000 in ?? ()
(gdb) p *(arch_spinlock_t *)0xffff88023ffe8240
$1 = {{head_tail = 3441806612, tickets = {head = 52500, tail = 52517}}}
(gdb) t 2
[Switching to thread 2 (Thread 2)]
#0 native_halt () at ./arch/x86/include/asm/irqflags.h:55
55 }
(gdb) bt
#0 native_halt () at ./arch/x86/include/asm/irqflags.h:55
#1 0xffffffff81037c27 in halt () at ./arch/x86/include/asm/paravirt.h:116
#2 kvm_lock_spinning (lock=0xffff88023ffe8240, want=52502) at
arch/x86/kernel/kvm.c:786
#3 0xffffffff81037251 in __raw_callee_save_kvm_lock_spinning ()
#4 0x0000000000000246 in irq_stack_union ()
#5 0x0000000000080750 in ?? ()
#6 0x0000000000020000 in ?? ()
#7 0x0000000000000004 in irq_stack_union ()
#8 0x000000000000cd16 in nmi_print_seq ()
Cannot access memory at address 0xbfc0
(gdb) t 3
[Switching to thread 3 (Thread 3)]
#0 native_halt () at ./arch/x86/include/asm/irqflags.h:55
55 }
(gdb) bt
#0 native_halt () at ./arch/x86/include/asm/irqflags.h:55
#1 0xffffffff81037c27 in halt () at ./arch/x86/include/asm/paravirt.h:116
#2 kvm_lock_spinning (lock=0xffff88023ffe8240, want=52512) at
arch/x86/kernel/kvm.c:786
#3 0xffffffff81037251 in __raw_callee_save_kvm_lock_spinning ()
#4 0xffff88023fc8edb0 in ?? ()
#5 0x0000000000000000 in ?? ()
[...] //other threads with similar output
(gdb) t 8
[Switching to thread 8 (Thread 8)]
#0 native_halt () at ./arch/x86/include/asm/irqflags.h:55
55 }
(gdb) bt
#0 native_halt () at ./arch/x86/include/asm/irqflags.h:55
#1 0xffffffff81037c27 in halt () at ./arch/x86/include/asm/paravirt.h:116
#2 kvm_lock_spinning (lock=0xffff88023ffe8240, want=52500) at
arch/x86/kernel/kvm.c:786
#3 0xffffffff81037251 in __raw_callee_save_kvm_lock_spinning ()
#4 0xffff88023fdcedb0 in ?? ()
#5 0x0000000000000000 in ?? ()
next prev parent reply other threads:[~2015-02-08 17:57 UTC|newest]
Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-06 14:49 [PATCH] x86 spinlock: Fix memory corruption on completing completions Raghavendra K T
2015-02-06 15:20 ` Sasha Levin
2015-02-06 15:20 ` Sasha Levin
2015-02-06 16:15 ` Linus Torvalds
2015-02-06 16:15 ` Linus Torvalds
2015-02-06 16:15 ` Linus Torvalds
2015-02-06 16:15 ` Linus Torvalds
2015-02-06 17:03 ` Andrey Ryabinin
2015-02-06 17:03 ` Andrey Ryabinin
2015-02-06 17:03 ` Andrey Ryabinin
2015-02-06 17:03 ` Andrey Ryabinin
2015-02-08 17:14 ` Oleg Nesterov
2015-02-08 17:14 ` Oleg Nesterov
2015-02-08 17:14 ` Oleg Nesterov
2015-02-06 15:20 ` Sasha Levin
2015-02-06 16:25 ` Linus Torvalds
2015-02-06 16:25 ` Linus Torvalds
2015-02-06 16:25 ` Linus Torvalds
2015-02-06 16:25 ` Linus Torvalds
2015-02-06 19:42 ` Davidlohr Bueso
2015-02-06 19:42 ` Davidlohr Bueso
2015-02-06 21:15 ` Sasha Levin
2015-02-06 21:15 ` Sasha Levin
2015-02-06 21:15 ` Sasha Levin
2015-02-06 21:15 ` Sasha Levin
2015-02-06 23:24 ` Davidlohr Bueso
2015-02-06 23:24 ` Davidlohr Bueso
2015-02-06 23:24 ` Davidlohr Bueso
2015-02-06 23:24 ` Davidlohr Bueso
2015-02-06 19:42 ` Davidlohr Bueso
2015-02-06 19:42 ` Davidlohr Bueso
2015-02-08 17:49 ` Raghavendra K T
2015-02-08 17:49 ` Raghavendra K T
2015-02-08 17:49 ` Raghavendra K T
2015-02-08 17:49 ` Raghavendra K T
2015-02-06 18:57 ` Sasha Levin
2015-02-06 18:57 ` Sasha Levin
2015-02-08 17:57 ` Raghavendra K T [this message]
2015-02-08 17:57 ` Raghavendra K T
2015-02-08 17:57 ` Raghavendra K T
2015-02-06 18:57 ` Sasha Levin
2015-02-08 21:14 ` Jeremy Fitzhardinge
2015-02-08 21:14 ` Jeremy Fitzhardinge
2015-02-09 9:34 ` Raghavendra K T
2015-02-09 9:34 ` Raghavendra K T
2015-02-09 12:02 ` Peter Zijlstra
2015-02-09 12:02 ` Peter Zijlstra
2015-02-09 12:02 ` Peter Zijlstra
2015-02-09 12:52 ` Raghavendra K T
2015-02-09 12:52 ` Raghavendra K T
2015-02-09 12:52 ` Raghavendra K T
2015-02-10 0:53 ` Linus Torvalds
2015-02-10 0:53 ` Linus Torvalds
2015-02-10 0:53 ` Linus Torvalds
2015-02-10 0:53 ` Linus Torvalds
2015-02-10 9:30 ` Raghavendra K T
2015-02-10 9:30 ` Raghavendra K T
2015-02-10 9:30 ` Raghavendra K T
2015-02-10 13:18 ` Denys Vlasenko
2015-02-10 13:18 ` Denys Vlasenko
2015-02-10 13:20 ` Denys Vlasenko
2015-02-10 13:20 ` Denys Vlasenko
2015-02-10 13:20 ` Denys Vlasenko
2015-02-10 13:20 ` Denys Vlasenko
2015-02-10 14:24 ` Oleg Nesterov
2015-02-10 14:24 ` Oleg Nesterov
2015-02-10 14:24 ` Oleg Nesterov
2015-02-10 14:24 ` Oleg Nesterov
2015-02-10 13:18 ` Denys Vlasenko
2015-02-10 13:18 ` Denys Vlasenko
2015-02-10 13:23 ` Sasha Levin
2015-02-10 13:23 ` Sasha Levin
2015-02-10 13:23 ` Sasha Levin
2015-02-10 13:26 ` Oleg Nesterov
2015-02-10 13:26 ` Oleg Nesterov
2015-02-11 1:18 ` Jeremy Fitzhardinge
2015-02-11 1:18 ` Jeremy Fitzhardinge
2015-02-11 1:18 ` Jeremy Fitzhardinge
2015-02-11 1:18 ` Jeremy Fitzhardinge
2015-02-11 17:24 ` Oleg Nesterov
2015-02-11 17:24 ` Oleg Nesterov
2015-02-11 17:24 ` Oleg Nesterov
2015-02-11 23:15 ` Jeremy Fitzhardinge
2015-02-11 23:15 ` Jeremy Fitzhardinge
2015-02-11 23:15 ` Jeremy Fitzhardinge
2015-02-11 23:15 ` Jeremy Fitzhardinge
2015-02-11 23:28 ` Linus Torvalds
2015-02-11 23:28 ` Linus Torvalds
2015-02-12 7:08 ` Jeremy Fitzhardinge
2015-02-12 7:08 ` Jeremy Fitzhardinge
2015-02-12 14:18 ` Oleg Nesterov
2015-02-12 14:18 ` Oleg Nesterov
2015-02-12 14:18 ` Oleg Nesterov
2015-02-12 14:18 ` Oleg Nesterov
2015-02-11 17:24 ` Oleg Nesterov
2015-02-11 11:08 ` Raghavendra K T
2015-02-11 11:08 ` Raghavendra K T
2015-02-11 17:38 ` Oleg Nesterov
2015-02-11 17:38 ` Oleg Nesterov
2015-02-11 18:38 ` Raghavendra K T
2015-02-11 18:38 ` Raghavendra K T
2015-02-11 18:38 ` Raghavendra K T
2015-02-11 18:38 ` Raghavendra K T
2015-02-11 17:38 ` Oleg Nesterov
2015-02-11 11:08 ` Raghavendra K T
2015-02-11 11:08 ` Raghavendra K T
2015-02-10 13:26 ` Oleg Nesterov
2015-02-09 9:34 ` Raghavendra K T
2015-02-08 21:14 ` Jeremy Fitzhardinge
-- strict thread matches above, loose matches on Subject: below --
2015-02-06 14:49 Raghavendra K T
2015-02-06 14:49 Raghavendra K T
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54D7A3A4.1030609@linux.vnet.ibm.com \
--to=raghavendra.kt@linux.vnet.ibm.com \
--cc=a.ryabinin@samsung.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@de.ibm.com \
--cc=davej@redhat.com \
--cc=hpa@zytor.com \
--cc=jasowang@redhat.com \
--cc=jeremy@goop.org \
--cc=konrad.wilk@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=paul.gortmaker@windriver.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=sasha.levin@oracle.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=waiman.long@hp.com \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.