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 @ > > 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
pgpRu2X0EJLDP.pgp
Description: PGP signature
