Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751249AbaDPAGm (ORCPT ); Tue, 15 Apr 2014 20:06:42 -0400 Received: from lgeamrelo01.lge.com ([156.147.1.125]:42850 "EHLO lgeamrelo01.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750993AbaDPAGl (ORCPT ); Tue, 15 Apr 2014 20:06:41 -0400 X-Original-SENDERIP: 10.177.220.145 X-Original-MAILFROM: iamjoonsoo.kim@lge.com Date: Wed, 16 Apr 2014 09:07:08 +0900 From: Joonsoo Kim To: Pekka Enberg Cc: Dave Jones , Christoph Lameter , Linux Kernel , Pekka Enberg , linux-mm@kvack.org, David Rientjes , Al Viro Subject: Re: oops in slab/leaks_show Message-ID: <20140416000708.GB14564@js1304-P5Q-DELUXE> References: <20140307025703.GA30770@redhat.com> <20140311003459.GA25657@lge.com> <20140311010135.GA25845@lge.com> <20140311012455.GA5151@redhat.com> <20140311025811.GA601@lge.com> <20140311083009.GA32004@lge.com> <53479B7B.6050008@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53479B7B.6050008@iki.fi> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 11, 2014 at 10:36:27AM +0300, Pekka Enberg wrote: > On 03/11/2014 10:30 AM, Joonsoo Kim wrote: > >---------8<--------------------- > > From ff6fe77fb764ca5bf8705bf53d07d38e4111e84c Mon Sep 17 00:00:00 2001 > >From: Joonsoo Kim > >Date: Tue, 11 Mar 2014 14:14:25 +0900 > >Subject: [PATCH] slab: remove kernel_map_pages() optimization in slab > > poisoning > > > >If CONFIG_DEBUG_PAGEALLOC enables, slab poisoning functionality uses > >kernel_map_pages(), instead of real poisoning, to detect memory corruption > >with low overhead. But, in that case, slab leak detector trigger oops. > >Reason is that slab leak detector accesses all active objects, especially > >including objects in cpu slab caches to get the caller information. > >These objects are already unmapped via kernel_map_pages() to detect memory > >corruption, so oops could be triggered. > > > >Following is oops message reported from Dave. > > > >It blew up when something tried to read /proc/slab_allocators > >(Just cat it, and you should see the oops below) > > > > Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > > Modules linked in: fuse hidp snd_seq_dummy tun rfcomm bnep llc2 af_key can_raw ipt_ULOG can_bcm nfnetlink scsi_transport_iscsi nfc caif_socket caif af_802154 phonet af_rxrpc can pppoe pppox ppp_generic > > +slhc irda crc_ccitt rds rose x25 atm netrom appletalk ipx p8023 psnap p8022 llc ax25 cfg80211 xfs coretemp hwmon x86_pkg_temp_thermal kvm_intel kvm crct10dif_pclmul crc32c_intel ghash_clmulni_intel > > +libcrc32c usb_debug microcode snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic pcspkr btusb bluetooth 6lowpan_iphc rfkill snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm > > +snd_timer e1000e snd ptp shpchp soundcore pps_core serio_raw > > CPU: 1 PID: 9386 Comm: trinity-c33 Not tainted 3.14.0-rc5+ #131 > > task: ffff8801aa46e890 ti: ffff880076924000 task.ti: ffff880076924000 > > RIP: 0010:[] [] handle_slab+0x8a/0x180 > > RSP: 0018:ffff880076925de0 EFLAGS: 00010002 > > RAX: 0000000000001000 RBX: 0000000000000000 RCX: 000000005ce85ce7 > > RDX: ffffea00079be100 RSI: 0000000000001000 RDI: ffff880107458000 > > RBP: ffff880076925e18 R08: 0000000000000001 R09: 0000000000000000 > > R10: 0000000000000000 R11: 000000000000000f R12: ffff8801e6f84000 > > R13: ffffea00079be100 R14: ffff880107458000 R15: ffff88022bb8d2c0 > > FS: 00007fb769e45740(0000) GS:ffff88024d040000(0000) knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: ffff8801e6f84ff8 CR3: 00000000a22db000 CR4: 00000000001407e0 > > DR0: 0000000002695000 DR1: 0000000002695000 DR2: 0000000000000000 > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000070602 > > Stack: > > ffff8802339dcfc0 ffff88022bb8d2c0 ffff880107458000 ffff88022bb8d2c0 > > ffff8802339dd008 ffff8802339dcfc0 ffffea00079be100 ffff880076925e68 > > ffffffffaa1ad9be ffff880203fe4f00 ffff88022bb8d318 0000000076925e98 > > Call Trace: > > [] leaks_show+0xce/0x240 > > [] seq_read+0x28e/0x490 > > [] proc_reg_read+0x3d/0x80 > > [] vfs_read+0x9b/0x160 > > [] SyS_read+0x58/0xb0 > > [] tracesys+0xd4/0xd9 > > Code: f5 00 00 00 0f 1f 44 00 00 48 63 c8 44 3b 0c 8a 0f 84 e3 00 00 00 83 c0 01 44 39 c0 72 eb 41 f6 47 1a 01 0f 84 e9 00 00 00 89 f0 <4d> 8b 4c 04 f8 4d 85 c9 0f 84 88 00 00 00 49 8b 7e 08 4d 8d 46 > > RIP [] handle_slab+0x8a/0x180 > > RSP > > CR2: ffff8801e6f84ff8 > > > >There are two solutions to fix the problem. One is to disable > >CONFIG_DEBUG_SLAB_LEAK if CONFIG_DEBUG_PAGEALLOC=y. The other is to remove > >kernel_map_pages() optimization in slab poisoning. I think that > >second one is better, since we can use all functionality with some more > >overhead. slab poisoning is already heavy operation, so adding more > >overhead doesn't weaken their value. > > > >Reported-by: Dave Jones > >Signed-off-by: Joonsoo Kim > > Joonsoo, can you please resend against slab/next? I'm seeing some > rejects here. > Hello Pekka. I send different patch to fix this bug. You can see it on following link. https://lkml.org/lkml/2014/4/15/727 With some more study, I found that using DEBUG_PAGEALLOC on SLAB is for not only optimization but also easily detection who corrupt memory. So, I change the solution to fix this bug. Please refer it. Thanks. -- 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/