Date: Wed, 29 Jan 2014 16:37:13 -0500 (EST) From: wollman@csail.mit.edu To: hps@bitfrost.no Cc: freebsd-scsi@freebsd.org, ken@freebsd.org, scottl@freebsd.org, freebsd-stable@freebsd.org Subject: Heap overflow in mps(4) (was: Re: stable/9 mps(4) rev 254938 == BOOM!) Message-ID: <201401292137.s0TLbD5G006716@hergotha.csail.mit.edu> In-Reply-To: <52E94FC2.1010901@bitfrost.no> References: <21225.19508.683025.581620@khavrinen.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <52E94FC2.1010901@bitfrost.no>, hps@bitfrost.no writes: >To me this sounds like someone is writing outside their assigned area. > >options DEBUG_REDZONE hselasky@ nails it! The mps(4) changes in stable/9 r254938 reliably cause a GPF during boot in non-debugging kernels, but adding DEBUG_REDZONE is sufficient to prevent the fault. Whichever heap allocation is being overrun does *not* ever get freed: there are no redzone messages on the console. (It also boots much faster with the new probing code, which is certainly a plus for debugging.) I can confirm that the tip of stable/9 (r261256) also works with DEBUG_REDZONE and fails without it. Only trouble is that I need to do performance testing, which DEBUG_REDZONE is not exactly going to help with. -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201401292137.s0TLbD5G006716>