Ed Maste wrote this message on Wed, Aug 05, 2015 at 03:24 +0000:
> 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.
It is possible, but this doesn't tell us who last used the bio, just
that when geli was allocating a bio, that the newly allocated bio was
modified while it was free...
It's likely that r284861 is just exposed a previously existing bug in
You could try to use memguard(9) to help catch the modification when
> 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 @
> 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 ---
> email@example.com mailing list
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"