From: Sasha Levin <sasha.levin@oracle.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
peterz@infradead.org, torvalds@linux-foundation.org
Cc: waiman.long@hp.com, jeremy@goop.org, ak@linux.intel.com,
a.ryabinin@samsung.com, xen-devel@lists.xenproject.org,
kvm@vger.kernel.org, konrad.wilk@oracle.com, riel@redhat.com,
x86@kernel.org, oleg@redhat.com, linux-kernel@vger.kernel.org,
paul.gortmaker@windriver.com, davej@redhat.com,
pbonzini@redhat.com, akpm@linux-foundation.org,
paulmck@linux.vnet.ibm.com,
virtualization@lists.linux-foundation.org,
borntraeger@de.ibm.com
Subject: Re: [PATCH] x86 spinlock: Fix memory corruption on completing completions
Date: Fri, 06 Feb 2015 13:57:08 -0500 [thread overview]
Message-ID: <54D50E84.2060703@oracle.com> (raw)
In-Reply-To: <1423234148-13886-1-git-send-email-raghavendra.kt@linux.vnet.ibm.com>
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:
[ 161.613469] BUG: spinlock lockup suspected on CPU#31, kworker/31:1/5213
[ 161.613469] lock: purge_lock.28981+0x0/0x40, .magic: dead4ead, .owner: kworker/7:1/6400, .owner_cpu: 7
[ 161.613469] CPU: 31 PID: 5213 Comm: kworker/31:1 Not tainted 3.19.0-rc7-next-20150204-sasha-00048-gee3a350 #1869
[ 161.613469] Workqueue: events bpf_prog_free_deferred
[ 161.613469] 0000000000000000 00000000f03dd27f ffff88056b227a88 ffffffffa1702276
[ 161.613469] 0000000000000000 ffff88017cf70000 ffff88056b227aa8 ffffffff9e1d009c
[ 161.613469] ffffffffa3edae60 0000000086c3f830 ffff88056b227ad8 ffffffff9e1d01d7
[ 161.613469] Call Trace:
[ 161.613469] dump_stack (lib/dump_stack.c:52)
[ 161.613469] spin_dump (kernel/locking/spinlock_debug.c:68 (discriminator 8))
[ 161.613469] do_raw_spin_lock (include/linux/nmi.h:48 kernel/locking/spinlock_debug.c:119 kernel/locking/spinlock_debug.c:137)
[ 161.613469] _raw_spin_lock (kernel/locking/spinlock.c:152)
[ 161.613469] ? __purge_vmap_area_lazy (mm/vmalloc.c:615)
[ 161.613469] __purge_vmap_area_lazy (mm/vmalloc.c:615)
[ 161.613469] ? vm_unmap_aliases (mm/vmalloc.c:1021)
[ 161.613469] vm_unmap_aliases (mm/vmalloc.c:1052)
[ 161.613469] ? vm_unmap_aliases (mm/vmalloc.c:1021)
[ 161.613469] ? __lock_acquire (kernel/locking/lockdep.c:2019 kernel/locking/lockdep.c:3184)
[ 161.613469] change_page_attr_set_clr (arch/x86/mm/pageattr.c:1394)
[ 161.613469] ? debug_object_deactivate (lib/debugobjects.c:463)
[ 161.613469] set_memory_rw (arch/x86/mm/pageattr.c:1662)
[ 161.613469] ? __lock_is_held (kernel/locking/lockdep.c:3518)
[ 161.613469] bpf_jit_free (include/linux/filter.h:377 arch/x86/net/bpf_jit_comp.c:991)
[ 161.613469] bpf_prog_free_deferred (kernel/bpf/core.c:646)
[ 161.613469] process_one_work (kernel/workqueue.c:2014 include/linux/jump_label.h:114 include/trace/events/workqueue.h:111 kernel/workqueue.c:2019)
[ 161.613469] ? process_one_work (./arch/x86/include/asm/atomic64_64.h:33 include/asm-generic/atomic-long.h:38 kernel/workqueue.c:598 kernel/workqueue.c:625 kernel/workqueue.c:2007)
[ 161.613469] worker_thread (include/linux/list.h:189 kernel/workqueue.c:2147)
[ 161.613469] ? process_one_work (kernel/workqueue.c:2091)
[ 161.613469] kthread (kernel/kthread.c:207)
[ 161.613469] ? finish_task_switch (./arch/x86/include/asm/current.h:14 kernel/sched/sched.h:1058 kernel/sched/core.c:2258)
[ 161.613469] ? flush_kthread_work (kernel/kthread.c:176)
[ 161.613469] ret_from_fork (arch/x86/kernel/entry_64.S:283)
[ 161.613469] ? flush_kthread_work (kernel/kthread.c:176)
And a few soft lockup messages inside the scheduler after that.
Thanks,
Sasha
WARNING: multiple messages have this Message-ID (diff)
From: Sasha Levin <sasha.levin@oracle.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
peterz@infradead.org, torvalds@linux-foundation.org
Cc: 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: Fri, 06 Feb 2015 13:57:08 -0500 [thread overview]
Message-ID: <54D50E84.2060703@oracle.com> (raw)
In-Reply-To: <1423234148-13886-1-git-send-email-raghavendra.kt@linux.vnet.ibm.com>
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:
[ 161.613469] BUG: spinlock lockup suspected on CPU#31, kworker/31:1/5213
[ 161.613469] lock: purge_lock.28981+0x0/0x40, .magic: dead4ead, .owner: kworker/7:1/6400, .owner_cpu: 7
[ 161.613469] CPU: 31 PID: 5213 Comm: kworker/31:1 Not tainted 3.19.0-rc7-next-20150204-sasha-00048-gee3a350 #1869
[ 161.613469] Workqueue: events bpf_prog_free_deferred
[ 161.613469] 0000000000000000 00000000f03dd27f ffff88056b227a88 ffffffffa1702276
[ 161.613469] 0000000000000000 ffff88017cf70000 ffff88056b227aa8 ffffffff9e1d009c
[ 161.613469] ffffffffa3edae60 0000000086c3f830 ffff88056b227ad8 ffffffff9e1d01d7
[ 161.613469] Call Trace:
[ 161.613469] dump_stack (lib/dump_stack.c:52)
[ 161.613469] spin_dump (kernel/locking/spinlock_debug.c:68 (discriminator 8))
[ 161.613469] do_raw_spin_lock (include/linux/nmi.h:48 kernel/locking/spinlock_debug.c:119 kernel/locking/spinlock_debug.c:137)
[ 161.613469] _raw_spin_lock (kernel/locking/spinlock.c:152)
[ 161.613469] ? __purge_vmap_area_lazy (mm/vmalloc.c:615)
[ 161.613469] __purge_vmap_area_lazy (mm/vmalloc.c:615)
[ 161.613469] ? vm_unmap_aliases (mm/vmalloc.c:1021)
[ 161.613469] vm_unmap_aliases (mm/vmalloc.c:1052)
[ 161.613469] ? vm_unmap_aliases (mm/vmalloc.c:1021)
[ 161.613469] ? __lock_acquire (kernel/locking/lockdep.c:2019 kernel/locking/lockdep.c:3184)
[ 161.613469] change_page_attr_set_clr (arch/x86/mm/pageattr.c:1394)
[ 161.613469] ? debug_object_deactivate (lib/debugobjects.c:463)
[ 161.613469] set_memory_rw (arch/x86/mm/pageattr.c:1662)
[ 161.613469] ? __lock_is_held (kernel/locking/lockdep.c:3518)
[ 161.613469] bpf_jit_free (include/linux/filter.h:377 arch/x86/net/bpf_jit_comp.c:991)
[ 161.613469] bpf_prog_free_deferred (kernel/bpf/core.c:646)
[ 161.613469] process_one_work (kernel/workqueue.c:2014 include/linux/jump_label.h:114 include/trace/events/workqueue.h:111 kernel/workqueue.c:2019)
[ 161.613469] ? process_one_work (./arch/x86/include/asm/atomic64_64.h:33 include/asm-generic/atomic-long.h:38 kernel/workqueue.c:598 kernel/workqueue.c:625 kernel/workqueue.c:2007)
[ 161.613469] worker_thread (include/linux/list.h:189 kernel/workqueue.c:2147)
[ 161.613469] ? process_one_work (kernel/workqueue.c:2091)
[ 161.613469] kthread (kernel/kthread.c:207)
[ 161.613469] ? finish_task_switch (./arch/x86/include/asm/current.h:14 kernel/sched/sched.h:1058 kernel/sched/core.c:2258)
[ 161.613469] ? flush_kthread_work (kernel/kthread.c:176)
[ 161.613469] ret_from_fork (arch/x86/kernel/entry_64.S:283)
[ 161.613469] ? flush_kthread_work (kernel/kthread.c:176)
And a few soft lockup messages inside the scheduler after that.
Thanks,
Sasha
next prev parent reply other threads:[~2015-02-06 18: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 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-06 16:15 ` Linus Torvalds
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 19:42 ` Davidlohr Bueso
2015-02-06 19:42 ` Davidlohr Bueso
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 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 21:15 ` Sasha Levin
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 16:25 ` Linus Torvalds
2015-02-06 18:57 ` Sasha Levin
2015-02-06 18:57 ` Sasha Levin [this message]
2015-02-06 18:57 ` Sasha Levin
2015-02-08 17:57 ` Raghavendra K T
2015-02-08 17:57 ` Raghavendra K T
2015-02-08 17:57 ` Raghavendra K T
2015-02-08 21:14 ` Jeremy Fitzhardinge
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 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-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 17:24 ` Oleg Nesterov
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: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 23:15 ` Jeremy Fitzhardinge
2015-02-11 23:15 ` Jeremy Fitzhardinge
2015-02-11 1:18 ` Jeremy Fitzhardinge
2015-02-11 11:08 ` Raghavendra K T
2015-02-11 11:08 ` Raghavendra K T
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 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-10 9:30 ` Raghavendra K T
2015-02-09 9:34 ` Raghavendra K T
-- 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=54D50E84.2060703@oracle.com \
--to=sasha.levin@oracle.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=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=raghavendra.kt@linux.vnet.ibm.com \
--cc=riel@redhat.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.