From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751860AbaBEGer (ORCPT ); Wed, 5 Feb 2014 01:34:47 -0500 Received: from relay.parallels.com ([195.214.232.42]:50153 "EHLO relay.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750720AbaBEGep (ORCPT ); Wed, 5 Feb 2014 01:34:45 -0500 Message-ID: <52F1DB81.30805@parallels.com> Date: Wed, 5 Feb 2014 10:34:41 +0400 From: Vladimir Davydov MIME-Version: 1.0 To: David Rientjes CC: Christoph Lameter , , , Subject: Re: [PATCH] slub: fix false-positive lockdep warning in free_partial() References: <1391517397-6142-1-git-send-email-vdavydov@parallels.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.24.25.216] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/05/2014 04:57 AM, David Rientjes wrote: > On Tue, 4 Feb 2014, Christoph Lameter wrote: > >>> Although this cannot actually result in a race, because on cache >>> destruction there should not be any concurrent frees or allocations from >>> the cache, let's add spin_lock/unlock to free_partial() just to keep >>> lockdep happy. >> Please add a comment that says this in the source so we know why this was >> added. >> > Makes sense since there is a comment there already saying we don't need > the lock, then with this patch we end up taking it away. The nice thing > is that there should be no lock contention here :) > > I'm not sure we need to disable irqs as in the patch, though. I'm afraid we need: ================================= [ INFO: inconsistent lock state ] 3.14.0-rc1-mm1+ #4 Tainted: G W --------------------------------- inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. modprobe/2760 [HC0[0]:SC0[0]:HE1:SE1] takes: (&(&n->list_lock)->rlock){?.-...}, at: [] __kmem_cache_shutdown+0x68/0x210 {IN-HARDIRQ-W} state was registered at: [] __lock_acquire+0x8f1/0x17f0 [] lock_acquire+0x92/0x120 [] _raw_spin_lock+0x39/0x70 [] deactivate_slab+0x26b/0x500 [] flush_cpu_slab+0x3c/0x70 [] generic_smp_call_function_single_interrupt+0x52/0xb0 [] smp_call_function_single_interrupt+0x22/0x40 [] call_function_single_interrupt+0x72/0x80 [] default_idle+0x1f/0xe0 [] arch_cpu_idle+0x26/0x30 [] cpu_startup_entry+0xa6/0x290 [] start_secondary+0x1d9/0x290 irq event stamp: 3883 hardirqs last enabled at (3883): [] mutex_lock_nested+0x2af/0x3d0 hardirqs last disabled at (3882): [] mutex_lock_nested+0x9f/0x3d0 softirqs last enabled at (3866): [] __do_softirq+0x1f2/0x330 softirqs last disabled at (3851): [] irq_exit+0xd5/0xe0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&n->list_lock)->rlock); lock(&(&n->list_lock)->rlock); *** DEADLOCK *** 1 lock held by modprobe/2760: #0: (slab_mutex){+.+.+.}, at: [] kmem_cache_destroy+0x22/0xf0 stack backtrace: CPU: 0 PID: 2760 Comm: modprobe Tainted: G W 3.14.0-rc1-mm1+ #4 Hardware name: ffffffff82295780 ffff88003af89c18 ffffffff816d9633 0000000000000002 ffff88007b2b0000 ffff88003af89c68 ffffffff810d1001 0000000000000000 ffffffff00000001 0000000000000001 ffffffff822957e8 ffff88007b2b0840 Call Trace: [] dump_stack+0x51/0x6e [] print_usage_bug+0x231/0x290 [] mark_lock+0x37f/0x420 [] __lock_acquire+0x789/0x17f0 [] ? wait_for_completion+0x5b/0x120 [] ? cpumask_next_and+0x23/0x40 [] ? slab_cpuup_callback+0x120/0x120 [] ? smp_call_function_many+0x5c/0x250 [] ? __kmem_cache_shutdown+0x68/0x210 [] lock_acquire+0x92/0x120 [] ? __kmem_cache_shutdown+0x68/0x210 [] ? set_page_slub_counters+0x40/0x40 [] _raw_spin_lock+0x39/0x70 [] ? __kmem_cache_shutdown+0x68/0x210 [] __kmem_cache_shutdown+0x68/0x210 [] kmem_cache_destroy+0x43/0xf0 [] xfs_qm_exit+0x15/0x30 [xfs] [] exit_xfs_fs+0x9/0x4e4 [xfs] [] SyS_delete_module+0x19a/0x1f0 [] ? retint_swapgs+0x13/0x1b [] ? trace_hardirqs_on_caller+0x105/0x1d0 [] ? trace_hardirqs_on_thunk+0x3a/0x3f [] system_call_fastpath+0x16/0x1b