Date: Thu, 6 Aug 2015 04:20:39 +0200 From: Michael Gmelin <freebsd@grem.de> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: Ed Maste <emaste@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Memory modified after free, seemingly geli related Message-ID: <20150806042039.78aa4ad3@bsd64.grem.de> In-Reply-To: <20150806020639.GA72832@garage.freebsd.pl> References: <CAPyFy2B3hN3z%2BTonbCDiKPxL5v53ZTtms1BXZgdofWzDzZ4X0A@mail.gmail.com> <20150806020639.GA72832@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 6 Aug 2015 04:06:40 +0200 Pawel Jakub Dawidek <pjd@FreeBSD.org> wrote: > On Wed, Aug 05, 2015 at 03:24:26AM +0000, Ed Maste wrote: > > I've encountered a few memory modified after free panics recently, > > which seem to be from geli. I don't yet have any debugging to > > completely confirm it's geli, but it has not happened on my other > > test laptop which configured similarly but without geli. > > > > This has a few local patches from my to-commit-to-HEAD queue. > > FreeBSD volta 11.0-CURRENT FreeBSD 11.0-CURRENT #10 > > r284409+6a002d9(staging): Tue Jul 7 17:57:01 EDT 2015 > > > > panic: Memory modified after free 0xfffff80009d504d8(248) val=0 @ > > 0xfffff80009d50518 > > I'm seeing it too. I tracked it down to ZFS. The bio was last owned by > the ZFS::VDEV GEOM class, which is modyfing bio_error on freed bio. > I'm investigating further and will let you know here once I find the > cause. > > > cpuid = 1 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfffffe011414a880 vpanic() at vpanic+0x189/frame 0xfffffe011414a900 > > panic() at panic+0x43/frame 0xfffffe011414a960 > > trash_ctor() at trash_ctor+0x48/frame 0xfffffe011414a970 > > uma_zalloc_arg() at uma_zalloc_arg+0x573/frame 0xfffffe011414a9e0 > > g_clone_bio() at g_clone_bio+0x1d/frame 0xfffffe011414aa00 > > g_eli_start() at g_eli_start+0xbd/frame 0xfffffe011414aa30 > > g_io_schedule_down() at g_io_schedule_down+0xe6/frame > > 0xfffffe011414aa60 g_down_procbody() at g_down_procbody+0x7d/frame > > 0xfffffe011414aa70 fork_exit() at fork_exit+0x84/frame > > 0xfffffe011414aab0 fork_trampoline() at fork_trampoline+0xe/frame > > 0xfffffe011414aab0 --- trap 0, rip = 0, rsp = 0xfffffe011414ab70, > > rbp = 0 --- > I've seen those as well while destroying 190.000 zfs snapshots (caused by an lpreserver runaway). Got four panics in the process, also running on top of geli. I'll mail you screenshots off-list. - Michael -- Michael Gmelin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150806042039.78aa4ad3>