On Thu, Aug 06, 2015 at 04:06:40AM +0200, Pawel Jakub Dawidek 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 _at_ > > 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. Ok. It was bio from ZFS in my case, but it was GELI which modified bio_error after delivering bio. This patch fixes the race: http://people.freebsd.org/~pjd/patches/geom_eli.patch Using bio after calling crypto_dispatch() is a bug. 'done' callbacks might have already called g_io_deliver() and upper layer might have already freed the bio. I'm not fully convinced that panic is the right response to crypto_dispatch() failure. It means that the driver failed our request and didn't call our callback, which is bad as we never complete the I/O. The crypto drivers tend to return errors only if the request itself is bogus, but that is program's bug and not a runtime condition. In other words panic should be fine here. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:59 UTC