All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: "D'Alessandro, Luke K" <ldalessa@indiana.edu>
Cc: lttng-dev <lttng-dev@lists.lttng.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: urcu lfht and free listing
Date: Fri, 10 Jun 2016 18:22:16 +0000 (UTC)	[thread overview]
Message-ID: <149868690.33139.1465582936951.JavaMail.zimbra__35513.7967890643$1465582963$gmane$org@efficios.com> (raw)
In-Reply-To: <BF41A9C3-FD22-4AF7-80DC-C172C252B92C@indiana.edu>

----- 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

       reply	other threads:[~2016-06-10 18:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <BF41A9C3-FD22-4AF7-80DC-C172C252B92C@indiana.edu>
2016-06-10 18:22 ` Mathieu Desnoyers [this message]
     [not found] ` <149868690.33139.1465582936951.JavaMail.zimbra@efficios.com>
2016-06-10 18:36   ` urcu lfht and free listing D'Alessandro, Luke K
     [not found]   ` <36F8A95C-47D1-4D7C-AA2F-AA9B9A8B53BE@indiana.edu>
2016-06-10 18:46     ` Mathieu Desnoyers
2016-06-10 10:58 D'Alessandro, Luke K

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='149868690.33139.1465582936951.JavaMail.zimbra__35513.7967890643$1465582963$gmane$org@efficios.com' \
    --to=mathieu.desnoyers@efficios.com \
    --cc=ldalessa@indiana.edu \
    --cc=lttng-dev@lists.lttng.org \
    --cc=paulmck@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
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.