[lttng-dev] urcu lfht and free listing

[D'Alessandro, Luke K]

> On Jun 10, 2016, at 2:22 PM, Mathieu Desnoyers <mathieu.desnoyers at efficios.com> wrote:
> 
> ----- On Jun 10, 2016, at 6:58 AM, D'Alessandro, Luke K ldalessa at indiana.edu wrote:
> 
>> Hi List,
>> 
>> Is it safe to free list and reuse hash table nodes (cds_lfht_node structures
>> used in cds_lfht_add_replace, cds_lfht_iter_get_node/cds_lfht_del) without
>> going through a synchronize_rcu() barrier?
> 
> Hi,
> 
> No, it is not safe.
> 
> From rculfhash.h:
> 
> cds_lfht_del:
> 
> * After successful removal, a grace period must be waited for before
> * freeing the memory reserved for old node (which can be accessed with
> * cds_lfht_iter_get_node).
> 
> cds_lfht_add_replace:
> 
> * After successful replacement, a grace period must be waited for before
> * freeing the memory reserved for the returned node.
> 
> cds_lfht_replace:
> 
> * After successful replacement, a grace period must be waited for before
> * freeing the memory reserved for the old node (which can be accessed
> * with cds_lfht_iter_get_node).

Hi Mathieu,

Thanks for the response.

I did read that documentation but it only references “freeing” the memory which I read as “returning the memory to the allocator via free()” which can sometimes be an issue as it can cascade into an munmap that is concurrent with some reader. I wasn’t sure if simply reusing the memory was a problem.

> You can either invoke synchronize_rcu() before re-using or freeing
> the removed node, or use the call_rcu() or defer_rcu() mechanisms to
> defer reclaim after a grace period (handled by worker threads).

Great, thank you.

Thanks,

Luke

> 
> Thanks,
> 
> Mathieu
> 
>> 
>> Thanks,
>> Luke
>> _______________________________________________
>> lttng-dev mailing list
>> lttng-dev at lists.lttng.org
>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20160610/4bdf2613/attachment.sig>