* urcu lfht and free listing @ 2016-06-10 10:58 D'Alessandro, Luke K 0 siblings, 0 replies; 4+ messages in thread From: D'Alessandro, Luke K @ 2016-06-10 10:58 UTC (permalink / raw) To: lttng-dev 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? Thanks, Luke _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <BF41A9C3-FD22-4AF7-80DC-C172C252B92C@indiana.edu>]
* Re: urcu lfht and free listing [not found] <BF41A9C3-FD22-4AF7-80DC-C172C252B92C@indiana.edu> @ 2016-06-10 18:22 ` Mathieu Desnoyers [not found] ` <149868690.33139.1465582936951.JavaMail.zimbra@efficios.com> 1 sibling, 0 replies; 4+ messages in thread From: Mathieu Desnoyers @ 2016-06-10 18:22 UTC (permalink / raw) To: D'Alessandro, Luke K; +Cc: lttng-dev, Paul E. McKenney ----- On Jun 10, 2016, at 6:58 AM, D'Alessandro, Luke K ldalessa@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). 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). Thanks, Mathieu > > Thanks, > Luke > _______________________________________________ > lttng-dev mailing list > lttng-dev@lists.lttng.org > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <149868690.33139.1465582936951.JavaMail.zimbra@efficios.com>]
* Re: urcu lfht and free listing [not found] ` <149868690.33139.1465582936951.JavaMail.zimbra@efficios.com> @ 2016-06-10 18:36 ` D'Alessandro, Luke K [not found] ` <36F8A95C-47D1-4D7C-AA2F-AA9B9A8B53BE@indiana.edu> 1 sibling, 0 replies; 4+ messages in thread From: D'Alessandro, Luke K @ 2016-06-10 18:36 UTC (permalink / raw) To: Mathieu Desnoyers; +Cc: lttng-dev, Paul E. McKenney [-- Attachment #1.1: Type: text/plain, Size: 1973 bytes --] > On Jun 10, 2016, at 2:22 PM, Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote: > > ----- On Jun 10, 2016, at 6:58 AM, D'Alessandro, Luke K ldalessa@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@lists.lttng.org >> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > > -- > Mathieu Desnoyers > EfficiOS Inc. > http://www.efficios.com [-- Attachment #1.2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 842 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <36F8A95C-47D1-4D7C-AA2F-AA9B9A8B53BE@indiana.edu>]
* Re: urcu lfht and free listing [not found] ` <36F8A95C-47D1-4D7C-AA2F-AA9B9A8B53BE@indiana.edu> @ 2016-06-10 18:46 ` Mathieu Desnoyers 0 siblings, 0 replies; 4+ messages in thread From: Mathieu Desnoyers @ 2016-06-10 18:46 UTC (permalink / raw) To: D'Alessandro, Luke K; +Cc: lttng-dev, Paul E. McKenney ----- On Jun 10, 2016, at 2:36 PM, D'Alessandro, Luke K ldalessa@indiana.edu wrote: >> On Jun 10, 2016, at 2:22 PM, Mathieu Desnoyers <mathieu.desnoyers@efficios.com> >> wrote: >> >> ----- On Jun 10, 2016, at 6:58 AM, D'Alessandro, Luke K ldalessa@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. Indeed, it could be clearer. I just updated the comments in the master branch. commit 5002434419b458f1de889b3ed1110b440d3bf5b0 Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Date: Fri Jun 10 14:43:40 2016 -0400 rculfhash: Documentation: clarify need for grace period before "re-using" Grace period must be waited for in case a node removed from the hash table is re-used, similarly to the reclaim use-case. Reported-by: Luke K D'Alessandro <ldalessa@indiana.edu> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Thanks! Mathieu > >> 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@lists.lttng.org >>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev >> >> -- >> Mathieu Desnoyers >> EfficiOS Inc. > > http://www.efficios.com -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-06-10 18:46 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-10 10:58 urcu lfht and free listing D'Alessandro, Luke K
[not found] <BF41A9C3-FD22-4AF7-80DC-C172C252B92C@indiana.edu>
2016-06-10 18:22 ` Mathieu Desnoyers
[not found] ` <149868690.33139.1465582936951.JavaMail.zimbra@efficios.com>
2016-06-10 18:36 ` D'Alessandro, Luke K
[not found] ` <36F8A95C-47D1-4D7C-AA2F-AA9B9A8B53BE@indiana.edu>
2016-06-10 18:46 ` Mathieu Desnoyers
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.