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:


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

Attachment: pgpRu2X0EJLDP.pgp
Description: PGP signature

Reply via email to