From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 03:14:33 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C520D16A420 for ; Tue, 28 Jun 2005 03:14:33 +0000 (GMT) (envelope-from silby@silby.com) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 7A40C43D48 for ; Tue, 28 Jun 2005 03:14:33 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 57664 invoked from network); 28 Jun 2005 03:14:32 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 28 Jun 2005 03:14:32 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 27 Jun 2005 22:14:15 -0500 (CDT) From: Mike Silbersack To: current@freebsd.org Message-ID: <20050627221332.X18909@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: memguard for mbufs (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2005 03:14:33 -0000 Here's a note I just sent to the people who have been experiencing "memory used after free" panics - if you're also affected, please try the described change as well. Thanks, Mike "Silby" Silbersack ---------- Forwarded message ---------- Date: Mon, 27 Jun 2005 22:13:21 -0500 (CDT) From: Mike Silbersack To: Peter Holm Cc: Andrey Chernov , Thierry Herbelot Subject: Re: memguard for mbufs On Mon, 27 Jun 2005, Peter Holm wrote: > On Mon, Jun 27, 2005 at 04:21:54AM -0500, Mike Silbersack wrote: > >> >> When memguard trips (which I did test with a trivial mbuf overwrite), >> it'll immediately trap and enter ddb - there will be no helpful message >> about use after free or anything. So, when that happens, take a trace. >> Hopefully everyone will report the same backtrace, and we'll have our >> culprit. :) >> > > I have now been stress testing for 0+04:10:05 without any panics. > > I'll let the test run the nite over. If I still don't get a panic I > plan to add a second NIC and revert to the previous kernel. This may > tell if the problem is related to the rl driver or not. > > - Peter Well, there's a reason for that. Bosko doublechecked my original mbuf use after free patch and found an error. I'll provide a "manual patch", since this is a three line change. Go into kern_mbuf.c, and find the procedure mb_fini_pack: static void mb_fini_pack(void *mem, int size) { struct mbuf *m; m = (struct mbuf *)mem; #ifdef INVARIANTS trash_fini(m->m_ext.ext_buf, MCLBYTES); #endif uma_zfree_arg(zone_clust, m->m_ext.ext_buf, NULL); m->m_ext.ext_buf = NULL; mbstat.m_mclusts += 1; /* XXX */ #ifdef INVARIANTS trash_fini(mem, size); #endif } Add those last three lines in, and everything should be peachy. Those of you running the memguard patch will have to take that back off, of course. The problem arose because there are three UMA zones - the mbuf zone, the clust zone, and the packet zone. Well, under certain memory conditions, objects from the packet zone are freed back into the mbuf. And, since I was only running the trash function on the mbuf and clust zones, this led to false errors when something from the packet zone was freed back to the mbuf zone. Sorry for all the debugging time, I hope this fixes the issue. Mike "Silby" Silbersack