line 4916, we can't just assert that b_tmp_cdata==NULL? I.e. there are
cases where it is non-NULL but we should ignore it because b_compress==OFF?
Should we be initializing b_tmp_cdata to NULL to prevent that?
The code in arc_buf_l2_cdata_free() and arc_buf_data_free() is very
similar. I think we should be able to reuse some of that code, e.g. do
something like:
static void
arc_buf_l2_cdata_free(arc_buf_hdr_t *hdr)
{
l2arc_buf_hdr_t *l2hdr = hdr->b_l2hdr;
l2arc_data_free_t *df;
ASSERT(MUTEX_HELD(&l2arc_buflist_mtx));
if (l2hdr->b_tmp_cdata == NULL ||
l2hdr->b_compress != ZIO_COMPRESS_LZ4)
return;
ASSERT(HDR_L2_WRITING(hdr));
arc_data_free(hdr, l2hdr->b_tmp_cdata, zio_data_buf_free);
l2hdr->b_tmp_cdata = NULL;
}
and arc_buf_data_free() is turned into arc_data_free() which takes the
arc_buf_hdr_t* and "void *data". Calls to arc_buf_data_free(buf,
func) turn into arc_data_free(buf->b_hdr, buf->b_data, func).
--matt
On Thu, Feb 20, 2014 at 3:05 AM, Andriy Gapon <[email protected]> wrote:
>
> To recap: after reports from FreeBSD ZFS users, I was able to capture two
> types
> of l2arc temporary compressions buffer leaks.
> One was in arc_release() called from dbuf_dirty().
> The other was in arc_hdr_destroy() called from arc_write_done() in the
> ZIO_FLAG_IO_REWRITE case.
> In both case the mentioned calls happened concurrently with l2arc writes
> and the
> corresponding buffers were in ARC_L2_WRITING state.
> Perhaps there were more cases...
>
> So, here is my current patch for the issue:
>
> https://github.com/avg-I/freebsd/compare/master...wip;hc;l2arc-compression-memory-leak.diff
> Drop .diff to get a github branch comparison interface for more details,
> if wanted.
>
> An earlier version of this patch has already been successfully tested by
> the
> original reporters. The patch also survives HybridCluster testing without
> any
> leaks or triggered assertions.
>
> Please review and comment.
> Thank you!
> --
> Andriy Gapon
>
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer
