Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753274Ab2KGPzw (ORCPT ); Wed, 7 Nov 2012 10:55:52 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:48285 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750922Ab2KGPzv (ORCPT ); Wed, 7 Nov 2012 10:55:51 -0500 Message-ID: <509A83F8.6040402@oracle.com> Date: Wed, 07 Nov 2012 10:53:28 -0500 From: Sasha Levin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121024 Thunderbird/16.0.1 MIME-Version: 1.0 To: Glauber Costa CC: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , kamezawa.hiroyu@jp.fujitsu.com, Johannes Weiner , Tejun Heo , Michal Hocko , Christoph Lameter , Pekka Enberg , David Rientjes , Pekka Enberg , Suleiman Souhlal , Dave Jones Subject: Re: [PATCH v6 28/29] slub: slub-specific propagation changes. References: <1351771665-11076-1-git-send-email-glommer@parallels.com> <1351771665-11076-29-git-send-email-glommer@parallels.com> In-Reply-To: <1351771665-11076-29-git-send-email-glommer@parallels.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 7502 Lines: 142 On 11/01/2012 08:07 AM, Glauber Costa wrote: > SLUB allows us to tune a particular cache behavior with sysfs-based > tunables. When creating a new memcg cache copy, we'd like to preserve > any tunables the parent cache already had. > > This can be done by tapping into the store attribute function provided > by the allocator. We of course don't need to mess with read-only > fields. Since the attributes can have multiple types and are stored > internally by sysfs, the best strategy is to issue a ->show() in the > root cache, and then ->store() in the memcg cache. > > The drawback of that, is that sysfs can allocate up to a page in > buffering for show(), that we are likely not to need, but also can't > guarantee. To avoid always allocating a page for that, we can update the > caches at store time with the maximum attribute size ever stored to the > root cache. We will then get a buffer big enough to hold it. The > corolary to this, is that if no stores happened, nothing will be > propagated. > > It can also happen that a root cache has its tunables updated during > normal system operation. In this case, we will propagate the change to > all caches that are already active. > > Signed-off-by: Glauber Costa > CC: Christoph Lameter > CC: Pekka Enberg > CC: Michal Hocko > CC: Kamezawa Hiroyuki > CC: Johannes Weiner > CC: Suleiman Souhlal > CC: Tejun Heo > --- Hi guys, This patch is making lockdep angry! *bark bark* [ 351.935003] ====================================================== [ 351.937693] [ INFO: possible circular locking dependency detected ] [ 351.939720] 3.7.0-rc4-next-20121106-sasha-00008-g353b62f #117 Tainted: G W [ 351.942444] ------------------------------------------------------- [ 351.943528] trinity-child13/6961 is trying to acquire lock: [ 351.943528] (s_active#43){++++.+}, at: [] sysfs_addrm_finish+0x31/0x60 [ 351.943528] [ 351.943528] but task is already holding lock: [ 351.943528] (slab_mutex){+.+.+.}, at: [] kmem_cache_destroy+0x22/0xe0 [ 351.943528] [ 351.943528] which lock already depends on the new lock. [ 351.943528] [ 351.943528] [ 351.943528] the existing dependency chain (in reverse order) is: [ 351.943528] -> #1 (slab_mutex){+.+.+.}: [ 351.960334] [] lock_acquire+0x1aa/0x240 [ 351.960334] [] __mutex_lock_common+0x59/0x5a0 [ 351.960334] [] mutex_lock_nested+0x3f/0x50 [ 351.960334] [] slab_attr_store+0xde/0x110 [ 351.960334] [] sysfs_write_file+0xfa/0x150 [ 351.960334] [] vfs_write+0xb0/0x180 [ 351.960334] [] sys_pwrite64+0x60/0xb0 [ 351.960334] [] tracesys+0xe1/0xe6 [ 351.960334] -> #0 (s_active#43){++++.+}: [ 351.960334] [] __lock_acquire+0x14df/0x1ca0 [ 351.960334] [] lock_acquire+0x1aa/0x240 [ 351.960334] [] sysfs_deactivate+0x122/0x1a0 [ 351.960334] [] sysfs_addrm_finish+0x31/0x60 [ 351.960334] [] sysfs_remove_dir+0x89/0xd0 [ 351.960334] [] kobject_del+0x16/0x40 [ 351.960334] [] __kmem_cache_shutdown+0x40/0x60 [ 351.960334] [] kmem_cache_destroy+0x40/0xe0 [ 351.960334] [] mon_text_release+0x78/0xe0 [ 351.960334] [] __fput+0x122/0x2d0 [ 351.960334] [] ____fput+0x9/0x10 [ 351.960334] [] task_work_run+0xbe/0x100 [ 351.960334] [] do_exit+0x432/0xbd0 [ 351.960334] [] do_group_exit+0x84/0xd0 [ 351.960334] [] get_signal_to_deliver+0x81d/0x930 [ 351.960334] [] do_signal+0x3a/0x950 [ 351.960334] [] do_notify_resume+0x3e/0x90 [ 351.960334] [] int_signal+0x12/0x17 [ 351.960334] [ 351.960334] other info that might help us debug this: [ 351.960334] [ 351.960334] Possible unsafe locking scenario: [ 351.960334] [ 351.960334] CPU0 CPU1 [ 351.960334] ---- ---- [ 351.960334] lock(slab_mutex); [ 351.960334] lock(s_active#43); [ 351.960334] lock(slab_mutex); [ 351.960334] lock(s_active#43); [ 351.960334] [ 351.960334] *** DEADLOCK *** [ 351.960334] [ 351.960334] 2 locks held by trinity-child13/6961: [ 351.960334] #0: (mon_lock){+.+.+.}, at: [] mon_text_release+0x25/0xe0 [ 351.960334] #1: (slab_mutex){+.+.+.}, at: [] kmem_cache_destroy+0x22/0xe0 [ 351.960334] [ 351.960334] stack backtrace: [ 351.960334] Pid: 6961, comm: trinity-child13 Tainted: G W 3.7.0-rc4-next-20121106-sasha-00008-g353b62f #117 [ 351.960334] Call Trace: [ 351.960334] [] print_circular_bug+0x1fb/0x20c [ 351.960334] [] __lock_acquire+0x14df/0x1ca0 [ 351.960334] [] ? debug_check_no_locks_freed+0x185/0x1e0 [ 351.960334] [] lock_acquire+0x1aa/0x240 [ 351.960334] [] ? sysfs_addrm_finish+0x31/0x60 [ 351.960334] [] sysfs_deactivate+0x122/0x1a0 [ 351.960334] [] ? sysfs_addrm_finish+0x31/0x60 [ 351.960334] [] sysfs_addrm_finish+0x31/0x60 [ 351.960334] [] sysfs_remove_dir+0x89/0xd0 [ 351.960334] [] kobject_del+0x16/0x40 [ 351.960334] [] __kmem_cache_shutdown+0x40/0x60 [ 351.960334] [] kmem_cache_destroy+0x40/0xe0 [ 351.960334] [] mon_text_release+0x78/0xe0 [ 351.960334] [] __fput+0x122/0x2d0 [ 351.960334] [] ____fput+0x9/0x10 [ 351.960334] [] task_work_run+0xbe/0x100 [ 351.960334] [] do_exit+0x432/0xbd0 [ 351.960334] [] ? get_signal_to_deliver+0x8b9/0x930 [ 351.960334] [] ? get_lock_stats+0x22/0x70 [ 351.960334] [] ? put_lock_stats.isra.16+0xe/0x40 [ 351.960334] [] ? _raw_spin_unlock_irq+0x2b/0x80 [ 351.960334] [] do_group_exit+0x84/0xd0 [ 351.960334] [] get_signal_to_deliver+0x81d/0x930 [ 351.960334] [] ? put_lock_stats.isra.16+0xe/0x40 [ 351.960334] [] do_signal+0x3a/0x950 [ 351.960334] [] ? rcu_cleanup_after_idle+0x23/0x170 [ 351.960334] [] ? rcu_eqs_exit_common+0x64/0x3a0 [ 351.960334] [] ? rcu_user_enter+0x10d/0x140 [ 351.960334] [] ? rcu_user_exit+0xc5/0xf0 [ 351.960334] [] do_notify_resume+0x3e/0x90 [ 351.960334] [] int_signal+0x12/0x17 Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/