From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Kazantsev Subject: Re: PROBLEM: Memory leak (at least with SLUB) from "secpath_dup" (xfrm) in 3.5+ kernels Date: Mon, 22 Oct 2012 01:51:34 +0600 Message-ID: <20121022015134.4de457b9@sacrilege> References: <20121019205055.2b258d09@sacrilege> <20121019233632.26cf96d8@sacrilege> <20121020204958.4bc8e293@sacrilege> <20121021044540.12e8f4b7@sacrilege> <20121021062402.7c4c4cb8@sacrilege> <1350826183.13333.2243.camel@edumazet-glaptop> <20121021195701.7a5872e7@sacrilege> <20121022004332.7e3f3f29@sacrilege> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/YkuKUKk50/LcW+kp1e9gUQZ"; protocol="application/pgp-signature" Cc: Paul Moore , netdev@vger.kernel.org, linux-mm@kvack.org To: Eric Dumazet Return-path: In-Reply-To: <20121022004332.7e3f3f29@sacrilege> Sender: owner-linux-mm@kvack.org List-Id: netdev.vger.kernel.org --Sig_/YkuKUKk50/LcW+kp1e9gUQZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 22 Oct 2012 00:43:32 +0600 Mike Kazantsev wrote: > > On Sun, 21 Oct 2012 15:29:43 +0200 > > Eric Dumazet wrote: > >=20 > > >=20 > > > Did you try linux-3.7-rc2 (or linux-3.7-rc1) ? > > >=20 >=20 > I just built "torvalds/linux-2.6" (v3.7-rc2) and rebooted into it, > started same rsync-over-net test and got kmalloc-64 leaking (it went up > to tens of MiB until I stopped rsync, normally these are fixed at ~500 > KiB). >=20 > Unfortunately, I forgot to add slub_debug option and build kmemleak so > wasn't able to look at this case further, and when I rebooted with > these enabled/built, it was secpath_cache again. >=20 > So previously noted "slabtop showed 'kmalloc-64' being the 99% offender > in the past, but with recent kernels (3.6.1), it has changed to > 'secpath_cache'" seem to be incorrect, as it seem to depend not on > kernel version, but some other factor. >=20 > Guess I'll try to reboot a few more times to see if I can catch > kmalloc-64 leaking (instead of secpath_cache) again. >=20 I haven't been able to catch the aforementioned condition, but noticed that with v3.7-rc2, "hex dump" part seem to vary in kmemleak traces, and contain all sorts of random stuff, for example: unreferenced object 0xffff88002ae2de00 (size 56): comm "softirq", pid 0, jiffies 4295006317 (age 213.066s) hex dump (first 32 bytes): 01 00 00 00 01 00 00 00 20 9f f4 28 00 88 ff ff ........ ..(.... 2f 6f 72 67 2f 66 72 65 65 64 65 73 6b 74 6f 70 /org/freedesktop backtrace: [] kmemleak_alloc+0x21/0x3e [] kmem_cache_alloc+0xa5/0xb1 [] secpath_dup+0x1b/0x5a [] xfrm_input+0x64/0x484 [] xfrm6_rcv_spi+0x19/0x1b [] xfrm6_rcv+0x20/0x22 [] ip6_input_finish+0x203/0x31b [] ip6_input+0x1e/0x50 [] ip6_rcv_finish+0x65/0x69 [] ipv6_rcv+0x27f/0x2e0 [] __netif_receive_skb+0x5ba/0x65a [] netif_receive_skb+0x47/0x78 [] napi_skb_finish+0x21/0x54 [] napi_gro_receive+0xfd/0x10a [] rtl8169_poll+0x326/0x4fc [] net_rx_action+0x9f/0x188 Not sure if it's relevant though. --=20 Mike Kazantsev // fraggod.net --Sig_/YkuKUKk50/LcW+kp1e9gUQZ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlCEUkoACgkQASbOZpzyXnFuowCgquhqHAktCHeCWFtCKS4TR+bW oxAAoMtBBa1zPDZmFhNIhpPqJoSbJ6TK =KfUX -----END PGP SIGNATURE----- --Sig_/YkuKUKk50/LcW+kp1e9gUQZ-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org