Date: Thu, 26 May 2011 11:27:32 -0400 From: Arnaud Lacombe <lacombar@gmail.com> To: Joerg Wunsch <j@uriah.heep.sax.de> Cc: freebsd-net@freebsd.org Subject: Re: kern/157287: re0: INVARIANTS panic (Memory modified after free) Message-ID: <BANLkTinDZV%2BUEHuADfkfEVQC9vAvgSTjNQ@mail.gmail.com> In-Reply-To: <201105252040.p4PKeB6B082921@freefall.freebsd.org> References: <201105252040.p4PKeB6B082921@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
On Wed, May 25, 2011 at 4:40 PM, Joerg Wunsch <j@uriah.heep.sax.de> wrote:
> The following reply was made to PR kern/157287; it has been noted by GNAT=
S.
>
> From: Joerg Wunsch <j@uriah.heep.sax.de>
> To: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@FreeBSD.org
> Cc:
> Subject: Re: kern/157287: re0: INVARIANTS panic (Memory modified after fr=
ee)
> Date: Wed, 25 May 2011 22:33:13 +0200
>
> =A0Some more analysis on the stack trace:
>
> =A0re_attach+0x118a corresponds to re_allocmem(), line 1085:
>
> =A0 =A0 =A0 =A0 /* Allocate DMA'able memory for the RX ring */
>
> =A0 =A0 =A0 =A0 error =3D bus_dmamem_alloc(sc->rl_ldata.rl_rx_list_tag,
> =A0 =A0 =A0 =A0 =A0 =A0 (void **)&sc->rl_ldata.rl_rx_list,
> =A0 =A0 =A0 =A0 =A0 =A0 BUS_DMA_WAITOK | BUS_DMA_COHERENT | BUS_DMA_ZERO,
> =A0 =A0 =A0 =A0 =A0 =A0 &sc->rl_ldata.rl_rx_list_map);
>
> =A0callee bus_dmamem_alloc+0x8a is i386/i386/busdma_machdep.c,
> =A0bus_dmamem_alloc() line 526:
>
> =A0 =A0 =A0 =A0 /*
> =A0 =A0 =A0 =A0 =A0* XXX:
> =A0 =A0 =A0 =A0 =A0* (dmat->alignment < dmat->maxsize) is just a quick ha=
ck; the exact
> =A0 =A0 =A0 =A0 =A0* alignment guarantees of malloc need to be nailed dow=
n, and the
> =A0 =A0 =A0 =A0 =A0* code below should be rewritten to take that into acc=
ount.
> =A0 =A0 =A0 =A0 =A0*
> =A0 =A0 =A0 =A0 =A0* In the meantime, we'll warn the user if malloc gets =
it wrong.
> =A0 =A0 =A0 =A0 =A0*/
> =A0 =A0 =A0 =A0 if ((dmat->maxsize <=3D PAGE_SIZE) &&
> =A0 =A0 =A0 =A0 =A0 =A0(dmat->alignment < dmat->maxsize) &&
> =A0 =A0 =A0 =A0 =A0 =A0 dmat->lowaddr >=3D ptoa((vm_paddr_t)Maxmem)) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 *vaddr =3D malloc(dmat->maxsize, M_DEVBUF=
, mflags);
> =A0 =A0 =A0 =A0 } else {
>
> =A0I could not spot anything obvious though.
This would likely only be the trigger of the panic, following the
inconsistency. Finding the previous owner of the memory chunk would
give more clue, AFAIK, FreeBSD do record the IP of the last user of a
memory chunk (as does Linux' kmemcheck), so that might not be trivial
to find out.
- Arnaud
>
> =A0--
> =A0cheers, J"org =A0 =A0 =A0 =A0 =A0 =A0 =A0 .-.-. =A0 --... ...-- =A0 -.=
. . =A0DL8DTL
>
> =A0http://www.sax.de/~joerg/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0NIC: JW11-RIPE
> =A0Never trust an operating system you don't have sources for. ;-)
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTinDZV%2BUEHuADfkfEVQC9vAvgSTjNQ>