Heap overflow in mps(4) (was: Re: stable/9 mps(4) rev 254938 == BOOM!)

[Kenneth D. Merry]

On Wed, Jan 29, 2014 at 19:05:49 -0500, Garrett Wollman wrote:
> <<On Wed, 29 Jan 2014 15:15:14 -0700, "Kenneth D. Merry" <ken at freebsd.org> 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 at FreeBSD.ORG
-------------- next part --------------
==== //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);