From owner-freebsd-scsi@FreeBSD.ORG Fri Jan 31 00:33:57 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07532914; Fri, 31 Jan 2014 00:33:57 +0000 (UTC) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9425A164B; Fri, 31 Jan 2014 00:33:56 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id s0V0XhRn012850; Thu, 30 Jan 2014 17:33:43 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id s0V0XguJ012849; Thu, 30 Jan 2014 17:33:42 -0700 (MST) (envelope-from ken) Date: Thu, 30 Jan 2014 17:33:42 -0700 From: "Kenneth D. Merry" To: Garrett Wollman Subject: Re: Heap overflow in mps(4) (was: Re: stable/9 mps(4) rev 254938 == BOOM!) Message-ID: <20140131003342.GA11755@nargothrond.kdm.org> References: <21225.19508.683025.581620@khavrinen.csail.mit.edu> <201401292137.s0TLbD5G006716@hergotha.csail.mit.edu> <20140129221514.GA47535@nargothrond.kdm.org> <21225.38749.179621.454579@khavrinen.csail.mit.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <21225.38749.179621.454579@khavrinen.csail.mit.edu> User-Agent: Mutt/1.4.2i Cc: freebsd-scsi@freebsd.org, scottl@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 00:33:57 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jan 29, 2014 at 19:05:49 -0500, Garrett Wollman wrote: > < said: > > > Are you booting off of the controller? If not, could you try building mps > > as a module and unloading it? Perhaps the memory would get freed when the > > module is unloaded and the redzone code would show where the problem is. > > I built a memory-stick image and tried this. No redzone messages, but > the driver leaks 18 allocations (142336 bytes). The attached patch should fix the leaked allocations. I'm CCing Steve and Kashyap at LSI so that they can verify that this is the right place to do the mapping shutdown. I don't know yet why that particular change is causing problems. Perhaps it just moved things around and exposed an existing problem. The fact that the redzone code doesn't expose any problems makes it more likely that it is a problem other than a heap overflow. Since it is consistent, is there any chance you could hook up remote gdb to the box and poke around when it crashes? Perhaps you'll see something interesting that will point to the problem. Ken -- Kenneth Merry ken@FreeBSD.ORG --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mps_memory_leak.20140130.txt" ==== //depot/vendor/FreeBSD/stable/9/sys/dev/mps/mps.c#8 - /usr/home/kenm/perforce5/vendor/FreeBSD/stable/9/sys/dev/mps/mps.c ==== *** /tmp/tmp.75208.67 Thu Jan 30 17:13:27 2014 --- /usr/home/kenm/perforce5/vendor/FreeBSD/stable/9/sys/dev/mps/mps.c Thu Jan 30 17:12:59 2014 *************** *** 1621,1626 **** --- 1621,1629 ---- /* Turn off the watchdog */ mps_lock(sc); sc->mps_flags |= MPS_FLAGS_SHUTDOWN; + + mps_mapping_exit(sc); + mps_unlock(sc); /* Lock must not be held for this */ callout_drain(&sc->periodic); --bg08WKrSYDhXBjb5--