Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754833Ab3J0Uju (ORCPT ); Sun, 27 Oct 2013 16:39:50 -0400 Received: from mail-ve0-f176.google.com ([209.85.128.176]:33280 "EHLO mail-ve0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752195Ab3J0Ujs (ORCPT ); Sun, 27 Oct 2013 16:39:48 -0400 MIME-Version: 1.0 In-Reply-To: References: <525BD08C.2080101@t-online.de> Date: Sun, 27 Oct 2013 20:39:47 +0000 X-Google-Sender-Auth: a4Baufd4jLKF3RFNYS-uk2MPPTc Message-ID: Subject: Re: [BUG 3.12.rc4] Oops: unable to handle kernel paging request during shutdown From: Linus Torvalds To: Thomas Gleixner , Pablo Neira Ayuso , Patrick McHardy , Jozsef Kadlecsik , David Miller Cc: Knut Petersen , Ingo Molnar , Paul McKenney , =?UTF-8?B?RnLDqWTDqXJpYyBXZWlzYmVja2Vy?= , Greg KH , linux-kernel , Network Development , netfilter-devel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4341 Lines: 89 On Sun, Oct 27, 2013 at 8:20 PM, Linus Torvalds wrote: > > Appended is a warning I get with DEBUG_TIMER_OBJECTS. Seems to be a > device-mapper issue. .. and here's another one. This time it looks like nf_conntrack_free() is freeing something that has a delayed work in it (again, likely an embedded 'struct kobject'). Looks like it is the kmem_cache_destroy(net->ct.nf_conntrack_cachep); that triggers this. Which probably means that there are still slab entries on that slab cache or something, but I didn't dig any deeper.. David? Patrick? Pablo? Jozsef? Any ideas? This was immediately preceded by [ 1136.316280] kobject: 'nf_conntrack_ffff8800b74d0000' (ffff8801196fac78): kobject_uevent_env [ 1136.316287] kobject: 'nf_conntrack_ffff8800b74d0000' (ffff8801196fac78): fill_kobj_path: path = '/kernel/slab/nf_conntrack_ffff8800b74d0000' [ 1136.316331] kobject: 'nf_conntrack_ffff8800b74d0000' (ffff8801196fac78): kobject_release, parent (null) (delayed) and I think it's that delayed "kobject_release()" that triggers this. Notice that kobject_release() can be delayed *without* the magic kobject debugging option by simply having a reference count on it from some external source. So this particular issue is probably triggered by my extra debug options in this case (I'm running with all those nasty "try to find bad object freeing" options, and doing module unloading etc), but can happen without it (it's just very hard to trigger in practice without the debug options). Linus --- [ 1136.321294] ------------[ cut here ]------------ [ 1136.321305] WARNING: CPU: 2 PID: 2483 at lib/debugobjects.c:260 debug_print_object+0x83/0xa0() [ 1136.321311] ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x20 [ 1136.321313] Modules linked in: fuse nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT xt_conntrack bnep bluetooth ebtable_nat ebt [ 1136.321357] mfd_core mei snd_page_alloc snd_timer snd soundcore sony_laptop rfkill uinput dm_crypt crc32_pclmul crc32c_intel i915 i2c_algo_bit drm_kms_h [ 1136.321371] CPU: 2 PID: 2483 Comm: kworker/u8:2 Tainted: G W 3.12.0-rc6-00331-ga2ff82065b5b #2 [ 1136.321373] Hardware name: Sony Corporation SVP11213CXB/VAIO, BIOS R0270V7 05/17/2013 [ 1136.321378] Workqueue: netns cleanup_net [ 1136.321380] 0000000000000009 ffff8800a86cdbc8 ffffffff8160d4a2 ffff8800a86cdc10 [ 1136.321384] ffff8800a86cdc00 ffffffff810514e8 ffff8800b745f848 ffffffff81c365e0 [ 1136.321387] ffffffff819f9133 ffffffff81f34750 0000000000000001 ffff8800a86cdc60 [ 1136.321390] Call Trace: [ 1136.321398] [] dump_stack+0x45/0x56 [ 1136.321405] [] warn_slowpath_common+0x78/0xa0 [ 1136.321410] [] warn_slowpath_fmt+0x47/0x50 [ 1136.321414] [] debug_print_object+0x83/0xa0 [ 1136.321420] [] ? execute_in_process_context+0x90/0x90 [ 1136.321424] [] debug_check_no_obj_freed+0x20b/0x250 [ 1136.321429] [] ? kmem_cache_destroy+0x92/0x100 [ 1136.321433] [] kmem_cache_free+0x125/0x210 [ 1136.321436] [] kmem_cache_destroy+0x92/0x100 [ 1136.321443] [] nf_conntrack_cleanup_net_list+0x126/0x160 [nf_conntrack] [ 1136.321449] [] nf_conntrack_pernet_exit+0x6d/0x80 [nf_conntrack] [ 1136.321453] [] ops_exit_list.isra.3+0x53/0x60 [ 1136.321457] [] cleanup_net+0x100/0x1b0 [ 1136.321460] [] process_one_work+0x18e/0x430 [ 1136.321463] [] worker_thread+0x119/0x390 [ 1136.321467] [] ? manage_workers.isra.23+0x2a0/0x2a0 [ 1136.321470] [] kthread+0xbb/0xc0 [ 1136.321472] [] ? kthread_create_on_node+0x110/0x110 [ 1136.321477] [] ret_from_fork+0x7c/0xb0 [ 1136.321479] [] ? kthread_create_on_node+0x110/0x110 [ 1136.321481] ---[ end trace 25f53c192da70825 ]--- -- 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/