Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 6 Aug 2015 03:57:37 +0000
From:      Ed Maste <emaste@freebsd.org>
To:        Pawel Jakub Dawidek <pjd@freebsd.org>
Cc:        FreeBSD Current <freebsd-current@freebsd.org>
Subject:   Re: Memory modified after free, seemingly geli related
Message-ID:  <CAPyFy2BMoVvMw2N070ezzuMNx8XLMTxnAAXPggX8np==DcDjHQ@mail.gmail.com>
In-Reply-To: <20150806031157.GA1116@garage.freebsd.pl>
References:  <CAPyFy2B3hN3z%2BTonbCDiKPxL5v53ZTtms1BXZgdofWzDzZ4X0A@mail.gmail.com> <20150806020639.GA72832@garage.freebsd.pl> <20150806031157.GA1116@garage.freebsd.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
On 6 August 2015 at 03:11, Pawel Jakub Dawidek <pjd@freebsd.org> wrote:
>>
>> 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.

Ok, so this is (sadly) the same issue as PR 199705.

> 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.

The patch in the PR just discards the return value from
crypto_dispatch(). I'm happy either way, or perhaps a KASSERT.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2BMoVvMw2N070ezzuMNx8XLMTxnAAXPggX8np==DcDjHQ>