This is clearly a use-after-free problem, but it's not clear _why_ this is 
occurring. I don't know the code in this PR, but I'll try and see if I can 
reproduce this in-house with `kmem_flags=f` set, so we can get a stack trace of 
where this buffer was freed.

>From the dump posted above:
```
> ::stack
arc_buf_remove+0x16(0, ffffff03d3fc6d50)
arc_buf_destroy_impl+0x94(ffffff03d3fc6d50)
arc_evict_hdr+0xb3(ffffff03f5d487d8, ffffffffc001bdd0)
arc_evict_state_impl+0x154(ffffff03c9edccc0, 3, ffffff03f31ae0f0, 0, 21000)
arc_evict_state+0x12e(ffffffffc001b000, 0, 23000, 1)
arc_adjust_impl+0x44(ffffffffc001b000, 0, 35f65, 1)
arc_adjust+0xd9()
arc_reclaim_thread+0xae(0)
thread_start+8()
> ffffff03d3fc6d50::whatis
ffffff03d3fc6d50 is freed from arc_buf_t
> ffffff03d3fc6d50::print arc_buf_t
{
    b_hdr = 0
    b_next = 0
    b_evict_lock = {
        _opaque = [ 0 ]
    }
    b_data = 0
    b_flags = 0 (0)
}
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/489#issuecomment-364561277
------------------------------------------
openzfs-developer
Archives: 
https://openzfs.topicbox.com/groups/developer/discussions/T91797982fdd5b7d9-Mc59aa4f37a9e0aa34e8398a1
Powered by Topicbox: https://topicbox.com

Reply via email to