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: 32+ 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 16:15 ` Linus Torvalds
2015-02-06 17:03 ` Andrey Ryabinin
2015-02-08 17:14 ` Oleg Nesterov
2015-02-06 16:25 ` Linus Torvalds
2015-02-06 19:42 ` Davidlohr Bueso
2015-02-06 21:15 ` Sasha Levin
2015-02-06 23:24 ` Davidlohr Bueso
2015-02-08 17:49 ` Raghavendra K T
2015-02-06 18:57 ` Sasha Levin
2015-02-08 17:57 ` Raghavendra K T [this message]
2015-02-08 21:14 ` Jeremy Fitzhardinge
2015-02-09 9:34 ` Raghavendra K T
2015-02-09 12:02 ` Peter Zijlstra
2015-02-09 12:52 ` Raghavendra K T
2015-02-10 0:53 ` Linus Torvalds
2015-02-10 9:30 ` Raghavendra K T
2015-02-10 13:18 ` Denys Vlasenko
2015-02-10 13:20 ` Denys Vlasenko
2015-02-10 14:24 ` Oleg Nesterov
2015-02-10 13:23 ` Sasha Levin
2015-02-10 13:26 ` Oleg Nesterov
2015-02-11 1:18 ` Jeremy Fitzhardinge
2015-02-11 17:24 ` Oleg Nesterov
2015-02-11 23:15 ` Jeremy Fitzhardinge
2015-02-11 23:28 ` Linus Torvalds
2015-02-12 7:08 ` Jeremy Fitzhardinge
2015-02-12 14:18 ` Oleg Nesterov
2015-02-11 11:08 ` Raghavendra K T
2015-02-11 17:38 ` Oleg Nesterov
2015-02-11 18:38 ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).