[Bug 212168] [panic] [UFS] use-after-free panic (0xdeadc0dedeadc0de)

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212168

Kirk McKusick <mckusick at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |Open

--- Comment #1 from Kirk McKusick <mckusick at FreeBSD.org> ---
From:    Konstantin Belousov <kostikbel at gmail.com>
Date:    Fri, 26 Aug 2016 13:51:00 +0300
To:      Kirk McKusick <mckusick at mckusick.com>
Subject: Re: [Bug 212168] [panic] [UFS] use-after-free panic
         (0xdeadc0dedeadc0de)
Cc:      gjb at freebsd.org

On Thu, Aug 25, 2016 at 10:56:20PM -0700, Kirk McKusick wrote:
>> From:    bugzilla-noreply at freebsd.org
>> Date:    Fri, 26 Aug 2016 05:19:37 +0000
>> To:      freebsd-fs at FreeBSD.org
>> Subject: [Bug 212168] [panic] [UFS] use-after-free panic (0xdeadc0dedeadc0de)
>>
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212168
>>
>> Glen Barber <gjb at FreeBSD.org> changed:
>>
>>            What    |Removed                     |Added
>> ----------------------------------------------------------------------------
>>            Assignee|freebsd-bugs at FreeBSD.org    |freebsd-fs at 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 = 0;
        bp->b_iodone = NULL;
        bp->b_error = 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 == NULL, ("relpbuf with vp"));
        KASSERT(bp->b_bufobj == NULL, ("relpbuf with bufobj"));
+       KASSERT(LIST_EMPTY(&bp->b_dep), ("relpbuf with deps"));

        BUF_UNLOCK(bp);

-- 
You are receiving this mail because:
You are the assignee for the bug.