Date: Fri, 26 Aug 2016 15:25:41 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 212168] [panic] [UFS] use-after-free panic (0xdeadc0dedeadc0de) Message-ID: <bug-212168-3630-E6vMAqgT5s@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-212168-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-212168-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212168 Kirk McKusick <mckusick@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open --- Comment #1 from Kirk McKusick <mckusick@FreeBSD.org> --- From: Konstantin Belousov <kostikbel@gmail.com> Date: Fri, 26 Aug 2016 13:51:00 +0300 To: Kirk McKusick <mckusick@mckusick.com> Subject: Re: [Bug 212168] [panic] [UFS] use-after-free panic (0xdeadc0dedeadc0de) Cc: gjb@freebsd.org On Thu, Aug 25, 2016 at 10:56:20PM -0700, Kirk McKusick wrote: >> From: bugzilla-noreply@freebsd.org >> Date: Fri, 26 Aug 2016 05:19:37 +0000 >> To: freebsd-fs@FreeBSD.org >> Subject: [Bug 212168] [panic] [UFS] use-after-free panic (0xdeadc0dedead= c0de) >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212168 >> >> Glen Barber <gjb@FreeBSD.org> changed: >> >> What |Removed |Added >> ------------------------------------------------------------------------= ---- >> Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org > > My first guess is that a buffer is being allocated and is not initializing > the bp->b_dep list. Any thoughts? Which buffer would it be ? Note that buf_alloc() unconditionally performs LIST_INIT(&bp->b_dep). More, buf_free() calls buf_deallocate() for non-empty b_dep, which must panic much earlier. I can only think of pbuf which has dandling b_dep for your hypothesis, but then I do not understand how the dependencies could get attached to it, even if the current buffer is cluster. I put a trivial patch below to be extra careful with b_dep for pbufs. Please try it. But really I do think that this is for normal buffer and the issue is somewhere else. Of course, the fact that intensive testing on x86 and somewhat less extensive testing on ARM and other platform did not show anything similar makes the arm64 specific bug much more feasible theory. diff --git a/sys/vm/vm_pager.c b/sys/vm/vm_pager.c index fccd1c8..3e6c447 100644 --- a/sys/vm/vm_pager.c +++ b/sys/vm/vm_pager.c @@ -375,6 +375,7 @@ initpbuf(struct buf *bp) bp->b_ioflags =3D 0; bp->b_iodone =3D NULL; bp->b_error =3D 0; + LIST_INIT(&bp->b_dep); BUF_LOCK(bp, LK_EXCLUSIVE, NULL); } @@ -472,6 +473,7 @@ relpbuf(struct buf *bp, int *pfreecnt) KASSERT(bp->b_vp =3D=3D NULL, ("relpbuf with vp")); KASSERT(bp->b_bufobj =3D=3D NULL, ("relpbuf with bufobj")); + KASSERT(LIST_EMPTY(&bp->b_dep), ("relpbuf with deps")); BUF_UNLOCK(bp); --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-212168-3630-E6vMAqgT5s>