From owner-freebsd-bugs@FreeBSD.ORG Fri Oct 24 14:03:38 2014 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CDC6EED for ; Fri, 24 Oct 2014 14:03:38 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 53526965 for ; Fri, 24 Oct 2014 14:03:38 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9OE3cbK038659 for ; Fri, 24 Oct 2014 14:03:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 194577] mbuf packet header leakage when closing TUN devices Date: Fri, 24 Oct 2014 14:03:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: hselasky@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 14:03:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194577 --- Comment #1 from Hans Petter Selasky --- Hi, Here are some more mbuf allocations, after TUN close, which my test program did not mark as stuck: KDB: stack backtrace: db_trace_self_wrapper(c0a38777,c0a678ac,c06c87f0,c7bd3838,a,c7bd3880,5,ffffffff,0,0,c326fd18,c13eea14,c13eea10,c7bd3860,c06c824 e,c7bd3880,c7bd3874,c06c82fb,c0a678ac,c7bd3880) at db_trace_self_wrapper+0x26/frame 0xc7bd3818 kdb_backtrace(c0a678ac,b6,20,1,c0ab8680,...) at kdb_backtrace+0x2b/frame 0xc7bd3874 uma_zalloc_arg(c13e45a0,c7bd38ec,1,c0b0a194,c7bd3914,...) at uma_zalloc_arg+0x706/frame 0xc7bd38c4 rt_msg1(c7bd3914,30,c2a54800,0,0,...) at rt_msg1+0x59/frame 0xc7bd3900 rtsock_addrmsg(2,c3250e00,0,c2eee9b4,0,...) at rtsock_addrmsg+0x73/frame 0xc7bd3950 rtinit(c3250e00,2,0,c7bd3aa8,0,...) at rtinit+0x1a4/frame 0xc7bd3a58 tunclose(c3281800,7,2000,c2afc2f0,c7bd3abc,...) at tunclose+0x280/frame 0xc7bd3a80 devfs_close(c7bd3af4,c7bd3af4,c338cd50,7,c7bd3b18,...) at devfs_close+0x17f/frame 0xc7bd3ac4 VOP_CLOSE_APV(c0a99ce0,c7bd3af4,c0a40f74,141,c0ad08a0,...) at VOP_CLOSE_APV+0x4a/frame 0xc7bd3adc vn_close(c338cd50,7,c2956180,c2afc2f0,0,...) at vn_close+0x99/frame 0xc7bd3b18 vn_closefile(c314b460,c2afc2f0,c314b460,0,c2afc2f0,...) at vn_closefile+0x53/frame 0xc7bd3b74 devfs_close_f(c314b460,c2afc2f0,3000000,0,1,...) at devfs_close_f+0x34/frame 0xc7bd3b90 _fdrop(c314b460,c2afc2f0,0,c7bd3c00,2,0,0,c2b7d2d8,4,2,c7bd3c1c,c09b22e9,c2957760,288df000,2,0,c7bd3c10,c06462a4,1f,c314b460) at _fdrop+0x2d/frame 0xc7bd3bac closef(c314b460,c2afc2f0,0,c7bd3c38,c09b1d76,...) at closef+0x5b/frame 0xc7bd3c10 kern_close(c2afc2f0,6,c7bd3c98,c09bb3b2,c0aff1c0,...) at kern_close+0x18d/frame 0xc7bd3c48 syscall(c7bd3d08) at syscall+0x535/frame 0xc7bd3cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xc7bd3cfc --- syscall (6, FreeBSD ELF32, sys_close), eip = 0x283c2393, esp = 0xbfbfe37c, ebp = 0xbfbfe388 --- KDB: stack backtrace: db_trace_self_wrapper(c0a38777,c0a678ac,c06c87f0,c7bd380c,a,c7bd3854,5,ffffffff,0,0,c0ab35e0,c7bd3840,c0676dca,c7bd3834,c06c824 e,c7bd3854,c7bd3848,c06c82fb,c0a678ac,c7bd3854) at db_trace_self_wrapper+0x26/frame 0xc7bd37ec kdb_backtrace(c0a678ac,b6,20,1,c7bd38c0,...) at kdb_backtrace+0x2b/frame 0xc7bd3848 uma_zalloc_arg(c13e45a0,c7bd38c0,1,936,c7bd38e4,...) at uma_zalloc_arg+0x706/frame 0xc7bd3898 rt_msg1(c7bd38e4,30,0,c32eba00,c32eba1c,...) at rt_msg1+0x59/frame 0xc7bd38d4 rtsock_routemsg(2,c2a54800,0,c2eee9b4,0,...) at rtsock_routemsg+0x4f/frame 0xc7bd3920 rt_newaddrmsg_fib(2,c3250e00,0,c2eee9b4,0,...) at rt_newaddrmsg_fib+0x4e/frame 0xc7bd3950 rtinit(c3250e00,2,0,c7bd3aa8,0,...) at rtinit+0x1a4/frame 0xc7bd3a58 tunclose(c3281800,7,2000,c2afc2f0,c7bd3abc,...) at tunclose+0x280/frame 0xc7bd3a80 devfs_close(c7bd3af4,c7bd3af4,c338cd50,7,c7bd3b18,...) at devfs_close+0x17f/frame 0xc7bd3ac4 VOP_CLOSE_APV(c0a99ce0,c7bd3af4,c0a40f74,141,c0ad08a0,...) at VOP_CLOSE_APV+0x4a/frame 0xc7bd3adc vn_close(c338cd50,7,c2956180,c2afc2f0,0,...) at vn_close+0x99/frame 0xc7bd3b18 vn_closefile(c314b460,c2afc2f0,c314b460,0,c2afc2f0,...) at vn_closefile+0x53/frame 0xc7bd3b74 devfs_close_f(c314b460,c2afc2f0,3000000,0,1,...) at devfs_close_f+0x34/frame 0xc7bd3b90 _fdrop(c314b460,c2afc2f0,0,c7bd3c00,2,0,0,c2b7d2d8,4,2,c7bd3c1c,c09b22e9,c2957760,288df000,2,0,c7bd3c10,c06462a4,1f,c314b460) a t _fdrop+0x2d/frame 0xc7bd3bac closef(c314b460,c2afc2f0,0,c7bd3c38,c09b1d76,...) at closef+0x5b/frame 0xc7bd3c10 kern_close(c2afc2f0,6,c7bd3c98,c09bb3b2,c0aff1c0,...) at kern_close+0x18d/frame 0xc7bd3c48 syscall(c7bd3d08) at syscall+0x535/frame 0xc7bd3cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xc7bd3cfc --- syscall (6, FreeBSD ELF32, sys_close), eip = 0x283c2393, esp = 0xbfbfe37c, ebp = 0xbfbfe388 --- -- You are receiving this mail because: You are the assignee for the bug.