Date: Wed, 4 Dec 2013 18:07:43 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: nicolas dumont <nicolas.dumont@netasq.com>, Paolo Pinto <paolo.pinto@netasq.com>, freebsd-geom@freebsd.org Subject: Re: geom_uzip, panic: bio_length in mdstart_vnode() Message-ID: <20131205020742.GU55638@funkthat.com> In-Reply-To: <20131204162029.GV59496@kib.kiev.ua> References: <529F2748.2060900@netasq.com> <20131204162029.GV59496@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Konstantin Belousov wrote this message on Wed, Dec 04, 2013 at 18:20 +0200:
> On Wed, Dec 04, 2013 at 01:59:52PM +0100, Paolo Pinto wrote:
> > Hi list!
> >
> > My kernel is compiled with option INVARIANTS and I get a reproducible
> > kernel panic when trying to read data from a GEOM based compressed
> > memory disk:
> >
> > Unread portion of the kernel message buffer:
> > panic: bio_length 140288
> > cpuid = 3
> > KDB: stack backtrace:
> > #0 0xffffffff80909726 at kdb_backtrace+0x66
> > #1 0xffffffff808d0fa8 at panic+0x1d8
> > #2 0xffffffff80595949 at mdstart_vnode+0x619
>
> The issue is that geom_uzip creates bios which are larger than MAXPHYS.
Shouldn't geom_uzip be fixed to honor MAXPHYS?
> As a workaround, the following patch should be enough. It only fires
> assert when md really uses pbuf, and since geom_uzip knows nothing
> about unmapped bio, the assertion must not trigger.
Ummm... what's the point of MAXPHYS if we allow IO larger than it?
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131205020742.GU55638>