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
