From hai.yang at magic-shield.com Sun Dec 1 21:16:20 2019 From: hai.yang at magic-shield.com (=?utf-8?B?5p2o5rW3?=) Date: Mon, 2 Dec 2019 10:16:20 +0800 Subject: [lttng-dev] =?utf-8?b?5Zue5aSNOlJlOiAgZG9jdW1lbnRhdGlvbiBhYm91?= =?utf-8?q?t_CTF_event_payload?= In-Reply-To: <733360507.225.1574779654690.JavaMail.zimbra@efficios.com> References: <733360507.225.1574779654690.JavaMail.zimbra@efficios.com> Message-ID: Thanks Mathieu. If I understand correctly, lttng-modules output necessary information as lttng_statedump_file_descriptor, and it is a part of CTF. But when babeltrace parse CTF, it does not process those information. lttng-analyses is post-processing python scripts while babeltrace is realtime C parser. If we decide to extend babeltrace to support the filename-fd mapping like iolog functionality in lttng-analyses, any recommendation? Regards Hai   ------------------ Original ------------------ From:  "Mathieu Desnoyers" From michel.dagenais at polymtl.ca Tue Dec 3 13:27:02 2019 From: michel.dagenais at polymtl.ca (Michel Dagenais) Date: Tue, 3 Dec 2019 13:27:02 -0500 (EST) Subject: [lttng-dev] Open Source job working on LTTng and Trace Compass Message-ID: <1415088749.9630494.1575397622501.JavaMail.zimbra@polymtl.ca> >From the start of these tools, Polytechnique was involved in Research projects to design and prototype new advanced features for tracing, profiling and debugging parallel distributed heterogeneous systems with LTTng and Trace Compass. This work is conducted in collaboration with Ericsson, EfficiOS, Ciena and other industrial partners. Our group has 2 research associates, Genevi?ve Bastien and Naser Ezzati, who help the students prototype new features and help the LTTng, Trace Compass and Theia maintainers to integrate those new features. Naser is leaving to become a faculty member in Brock University in Ontario. We thus have a position open to join Genevi?ve and work on Open Source tracing tools in a flexible and dynamic environment. If this could be of interest to you, please contact me at michel.dagenais at polymtl.ca. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.desnoyers at efficios.com Thu Dec 5 01:58:06 2019 From: mathieu.desnoyers at efficios.com (Mathieu Desnoyers) Date: Thu, 5 Dec 2019 01:58:06 -0500 Subject: [lttng-dev] [PATCH babeltrace-1.5 3/6] Fix: lttng-live: lttng_live_open_trace_read memory leak In-Reply-To: <20191205065809.16728-1-mathieu.desnoyers@efficios.com> References: <20191205065809.16728-1-mathieu.desnoyers@efficios.com> Message-ID: <20191205065809.16728-4-mathieu.desnoyers@efficios.com> Signed-off-by: Mathieu Desnoyers --- formats/lttng-live/lttng-live-plugin.c | 1 + 1 file changed, 1 insertion(+) diff --git a/formats/lttng-live/lttng-live-plugin.c b/formats/lttng-live/lttng-live-plugin.c index ed52a995..0bebdd89 100644 --- a/formats/lttng-live/lttng-live-plugin.c +++ b/formats/lttng-live/lttng-live-plugin.c @@ -288,6 +288,7 @@ static int lttng_live_open_trace_read(const char *path) } end_free: + g_array_free(ctx->session_ids, TRUE); g_hash_table_destroy(ctx->session->ctf_traces); free_session_streams(ctx->session); g_free(ctx->session); -- 2.17.1 From mathieu.desnoyers at efficios.com Thu Dec 5 01:58:03 2019 From: mathieu.desnoyers at efficios.com (Mathieu Desnoyers) Date: Thu, 5 Dec 2019 01:58:03 -0500 Subject: [lttng-dev] [PATCH babeltrace-1.5 0/6] Babeltrace 1.5 lttng-live with per-pid ust buffers Message-ID: <20191205065809.16728-1-mathieu.desnoyers@efficios.com> This series of fixes comes from testing babeltrace 1.5 lttng-live under valgrind with per-pid lttng buffers. This was done in the context of testing of the "lttng clear" feature. Thanks, Mathieu Mathieu Desnoyers (6): Fix: lttng-live: use-after-free in get_next_index() Fix: trace-collection: trace clock use after free Fix: lttng-live: lttng_live_open_trace_read memory leak Fix: lib/iterator.c: unbalanced ctx put (leak) Fix: lttng-live: ctf_live_packet_seek stream hang up handling Fix: lttng-live format: do not error out on empty streams hang up formats/ctf/ctf.c | 7 ++++++- formats/lttng-live/lttng-live-comm.c | 8 ++++++-- formats/lttng-live/lttng-live-plugin.c | 1 + lib/iterator.c | 3 +++ lib/trace-collection.c | 21 ++++++++++++++++++--- 5 files changed, 34 insertions(+), 6 deletions(-) -- 2.17.1 From mathieu.desnoyers at efficios.com Thu Dec 5 01:58:04 2019 From: mathieu.desnoyers at efficios.com (Mathieu Desnoyers) Date: Thu, 5 Dec 2019 01:58:04 -0500 Subject: [lttng-dev] [PATCH babeltrace-1.5 1/6] Fix: lttng-live: use-after-free in get_next_index() In-Reply-To: <20191205065809.16728-1-mathieu.desnoyers@efficios.com> References: <20191205065809.16728-1-mathieu.desnoyers@efficios.com> Message-ID: <20191205065809.16728-2-mathieu.desnoyers@efficios.com> Running babeltrace under valgrind with a test-cases doing per-pid lttng tracing in live mode triggers this use-after-free in get_next_index() when stream is hung up. Signed-off-by: Mathieu Desnoyers --- formats/lttng-live/lttng-live-comm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/formats/lttng-live/lttng-live-comm.c b/formats/lttng-live/lttng-live-comm.c index 33a78029..96817f5e 100644 --- a/formats/lttng-live/lttng-live-comm.c +++ b/formats/lttng-live/lttng-live-comm.c @@ -1108,8 +1108,8 @@ retry: viewer_stream->in_trace = 0; bt_list_del(&viewer_stream->trace_stream_node); bt_list_del(&viewer_stream->session_stream_node); - g_free(viewer_stream); *stream_id = be64toh(rp->stream_id); + g_free(viewer_stream); break; case LTTNG_VIEWER_INDEX_ERR: fprintf(stderr, "[error] get_next_index: error\n"); -- 2.17.1 From mathieu.desnoyers at efficios.com Thu Dec 5 01:58:05 2019 From: mathieu.desnoyers at efficios.com (Mathieu Desnoyers) Date: Thu, 5 Dec 2019 01:58:05 -0500 Subject: [lttng-dev] [PATCH babeltrace-1.5 2/6] Fix: trace-collection: trace clock use after free In-Reply-To: <20191205065809.16728-1-mathieu.desnoyers@efficios.com> References: <20191205065809.16728-1-mathieu.desnoyers@efficios.com> Message-ID: <20191205065809.16728-3-mathieu.desnoyers@efficios.com> The trace collection should copy the trace clock object rather than take a reference to the first trace's trace clock, because it may be freed when the trace is removed (e.g. application going away in per-pid live tracing). Signed-off-by: Mathieu Desnoyers --- lib/trace-collection.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/lib/trace-collection.c b/lib/trace-collection.c index 035d2dc2..8e4a1432 100644 --- a/lib/trace-collection.c +++ b/lib/trace-collection.c @@ -76,7 +76,7 @@ static void clock_add(gpointer key, gpointer value, gpointer user_data) { struct clock_match *clock_match = user_data; GHashTable *tc_clocks = clock_match->clocks; - struct ctf_clock *t_clock = value; + struct ctf_clock *t_clock = value, *clock_copy; GQuark v; if (t_clock->absolute) @@ -104,9 +104,14 @@ static void clock_add(gpointer key, gpointer value, gpointer user_data) clock_match->tc->single_clock_offset_avg = clock_match->tc->offset_first; } + clock_copy = g_new0(struct ctf_clock, 1); + *clock_copy = *t_clock; + if (t_clock->description) { + clock_copy->description = g_strdup(t_clock->description); + } g_hash_table_insert(tc_clocks, (gpointer) (unsigned long) v, - value); + clock_copy); } else if (!t_clock->absolute) { int64_t diff_ns; @@ -209,11 +214,21 @@ int bt_trace_collection_remove(struct trace_collection *tc, } +static +void clock_free(gpointer data) +{ + struct ctf_clock *clock = data; + + g_free(clock->description); + g_free(clock); +} + void bt_init_trace_collection(struct trace_collection *tc) { assert(tc); tc->array = g_ptr_array_new(); - tc->clocks = g_hash_table_new(g_direct_hash, g_direct_equal); + tc->clocks = g_hash_table_new_full(g_direct_hash, g_direct_equal, + NULL, clock_free); tc->single_clock_offset_avg = 0; tc->offset_first = 0; tc->delta_offset_first_sum = 0; -- 2.17.1 From mathieu.desnoyers at efficios.com Thu Dec 5 01:58:07 2019 From: mathieu.desnoyers at efficios.com (Mathieu Desnoyers) Date: Thu, 5 Dec 2019 01:58:07 -0500 Subject: [lttng-dev] [PATCH babeltrace-1.5 4/6] Fix: lib/iterator.c: unbalanced ctx put (leak) In-Reply-To: <20191205065809.16728-1-mathieu.desnoyers@efficios.com> References: <20191205065809.16728-1-mathieu.desnoyers@efficios.com> Message-ID: <20191205065809.16728-5-mathieu.desnoyers@efficios.com> Missing context put in iterator init error path. Signed-off-by: Mathieu Desnoyers --- lib/iterator.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/iterator.c b/lib/iterator.c index 639a2d29..77093217 100644 --- a/lib/iterator.c +++ b/lib/iterator.c @@ -778,6 +778,8 @@ int bt_iter_init(struct bt_iter *iter, error: bt_heap_free(iter->stream_heap); error_heap_init: + bt_context_put(ctx); + iter->ctx = NULL; g_free(iter->stream_heap); iter->stream_heap = NULL; error_ctx: @@ -812,6 +814,7 @@ void bt_iter_fini(struct bt_iter *iter) } iter->ctx->current_iterator = NULL; bt_context_put(iter->ctx); + iter->ctx = NULL; } void bt_iter_destroy(struct bt_iter *iter) -- 2.17.1 From mathieu.desnoyers at efficios.com Thu Dec 5 01:58:08 2019 From: mathieu.desnoyers at efficios.com (Mathieu Desnoyers) Date: Thu, 5 Dec 2019 01:58:08 -0500 Subject: [lttng-dev] [PATCH babeltrace-1.5 5/6] Fix: lttng-live: ctf_live_packet_seek stream hang up handling In-Reply-To: <20191205065809.16728-1-mathieu.desnoyers@efficios.com> References: <20191205065809.16728-1-mathieu.desnoyers@efficios.com> Message-ID: <20191205065809.16728-6-mathieu.desnoyers@efficios.com> When get_next_index sets the index position to EOF, ctf_live_packet_seek() should in turn set the stream position to EOF to propagate the hung up state. Signed-off-by: Mathieu Desnoyers --- formats/lttng-live/lttng-live-comm.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/formats/lttng-live/lttng-live-comm.c b/formats/lttng-live/lttng-live-comm.c index 96817f5e..484c025d 100644 --- a/formats/lttng-live/lttng-live-comm.c +++ b/formats/lttng-live/lttng-live-comm.c @@ -1276,7 +1276,11 @@ retry: cur_index->packet_size, cur_index->offset, cur_index->content_size, cur_index->ts_cycles.timestamp_end); - + if (cur_index->offset == EOF) { + pos->offset = EOF; + ret = -BT_PACKET_SEEK_ERROR; + goto end; + } } /* -- 2.17.1 From mathieu.desnoyers at efficios.com Thu Dec 5 01:58:09 2019 From: mathieu.desnoyers at efficios.com (Mathieu Desnoyers) Date: Thu, 5 Dec 2019 01:58:09 -0500 Subject: [lttng-dev] [PATCH babeltrace-1.5 6/6] Fix: lttng-live format: do not error out on empty streams hang up In-Reply-To: <20191205065809.16728-1-mathieu.desnoyers@efficios.com> References: <20191205065809.16728-1-mathieu.desnoyers@efficios.com> Message-ID: <20191205065809.16728-7-mathieu.desnoyers@efficios.com> Attaching to a stream hung up before providing any trace packet causes ctf_open_mmap_stream_read() to return an error. This kind of scenario can happen with the upcoming "lttng clear" feature. Signed-off-by: Mathieu Desnoyers --- formats/ctf/ctf.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/formats/ctf/ctf.c b/formats/ctf/ctf.c index 980ebc9a..1ba9017f 100644 --- a/formats/ctf/ctf.c +++ b/formats/ctf/ctf.c @@ -2571,8 +2571,13 @@ int ctf_open_mmap_stream_read(struct ctf_trace *td, } ret = prepare_mmap_stream_definition(td, file_stream, packet_seek); - if (ret) + if (ret) { + /* We need to check for EOF here for empty files. */ + if (unlikely(file_stream->pos.offset == EOF)) { + ret = 0; + } goto error_index; + } /* * For now, only a single clock per trace is supported. -- 2.17.1 From ryx at gwmail.gwu.edu Thu Dec 5 20:17:50 2019 From: ryx at gwmail.gwu.edu (Yuxin Ren) Date: Thu, 5 Dec 2019 20:17:50 -0500 Subject: [lttng-dev] RCU consistency guarantees Message-ID: Hi, I am a student, and learning RCU now, but still know very little about it. Are there any documents/papers/materials which (in)formally define and explain RCU consistency guarantees? I know there are some consistency models in the database area (such as PRAM, Read Uncommitted, etc) from https://jepsen.io/consistency and [1]. How does RCU related to those consistency models? I also found some comments online (One key distinction is that both MVCC and RLU provide much stronger consistency guarantees to readers than does RCU ...) (https://lwn.net/Articles/777036/). I do not understand how we reason/dresibe/compare the consistency guarantees. ( I even do not know what consistency guarantees provided by RCU formally) Could someone explain this to me? [1] Bailis, P., Davidson, A., Fekete, A., Ghodsi, A., Hellerstein, J. M., & Stoica, I. (2013). Highly available transactions: Virtues and limitations. Proceedings of the VLDB Endowment, 7(3), 181-192. Thanks Yuxin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.desnoyers at efficios.com Fri Dec 6 05:49:09 2019 From: mathieu.desnoyers at efficios.com (Mathieu Desnoyers) Date: Fri, 6 Dec 2019 05:49:09 -0500 (EST) Subject: [lttng-dev] RCU consistency guarantees In-Reply-To: References: Message-ID: <194534011.751.1575629349181.JavaMail.zimbra@efficios.com> ----- On Dec 5, 2019, at 8:17 PM, Yuxin Ren wrote: > Hi, > I am a student, and learning RCU now, but still know very little about it. > Are there any documents/papers/materials which (in)formally define and explain > RCU consistency guarantees? You may want to have a look at User-Level Implementations of Read-Copy Update Article in IEEE Transactions on Parallel and Distributed Systems 23(2):375 - 382 ? March 2012 as a starting point. Thanks, Mathieu > I know there are some consistency models in the database area (such as PRAM, > Read Uncommitted, etc) from [ https://jepsen.io/consistency | > https://jepsen.io/consistency ] and [1]. > How does RCU related to those consistency models? > I also found some comments online (One key distinction is that both MVCC and RLU > provide much stronger consistency guarantees to readers than does RCU ...) ( [ > https://lwn.net/Articles/777036/ | https://lwn.net/Articles/777036/ ] ). > I do not understand how we reason/dresibe/compare the consistency guarantees. ( > I even do not know what consistency guarantees provided by RCU formally) > Could someone explain this to me? > [1] Bailis, P., Davidson, A., Fekete, A., Ghodsi, A., Hellerstein, J. M., & > Stoica, I. (2013). Highly available transactions: Virtues and limitations. > Proceedings of the VLDB Endowment, 7(3), 181-192. > Thanks > Yuxin > _______________________________________________ > 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 -------------- An HTML attachment was scrubbed... URL: From ryx at gwmail.gwu.edu Fri Dec 6 09:51:32 2019 From: ryx at gwmail.gwu.edu (Yuxin Ren) Date: Fri, 6 Dec 2019 09:51:32 -0500 Subject: [lttng-dev] RCU consistency guarantees In-Reply-To: <194534011.751.1575629349181.JavaMail.zimbra@efficios.com> References: <194534011.751.1575629349181.JavaMail.zimbra@efficios.com> Message-ID: On Fri, Dec 6, 2019 at 5:49 AM Mathieu Desnoyers < mathieu.desnoyers at efficios.com> wrote: > > ----- On Dec 5, 2019, at 8:17 PM, Yuxin Ren wrote: > > Hi, > I am a student, and learning RCU now, but still know very little about it. > Are there any documents/papers/materials which (in)formally define and > explain RCU consistency guarantees? > > > You may want to have a look at > > User-Level Implementations of Read-Copy Update > Article in IEEE Transactions on Parallel and Distributed Systems 23(2):375 > - 382 ? March 2012 > Thanks for your info. However, I do not think URCU talks about any consistency model formally. >From previous communication with Paul, he said RCU is not designed for linearizability, and it is totally acceptable that RCU is not linearizable. However, I am curious how to accurately/formally Characterize RCU consistency model/guarantees > > as a starting point. > > Thanks, > > Mathieu > > > I know there are some consistency models in the database area (such as > PRAM, Read Uncommitted, etc) from https://jepsen.io/consistency and [1]. > How does RCU related to those consistency models? > > I also found some comments online (One key distinction is that both MVCC > and RLU provide much stronger consistency guarantees to readers than does > RCU ...) (https://lwn.net/Articles/777036/). > I do not understand how we reason/dresibe/compare the > consistency guarantees. ( I even do not know what consistency guarantees > provided by RCU formally) > Could someone explain this to me? > > > > [1] Bailis, P., Davidson, A., Fekete, A., Ghodsi, A., Hellerstein, J. M., > & Stoica, I. (2013). Highly available transactions: Virtues and > limitations. Proceedings of the VLDB Endowment, 7(3), 181-192. > > Thanks > Yuxin > > _______________________________________________ > 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 -------------- An HTML attachment was scrubbed... URL: From ryx at gwmail.gwu.edu Thu Dec 5 20:15:10 2019 From: ryx at gwmail.gwu.edu (Yuxin Ren) Date: Thu, 5 Dec 2019 20:15:10 -0500 Subject: [lttng-dev] RCU consistency guarantees Message-ID: Hi, I am a student, and learning RCU now, but still know very little about it. Are there any documents/papers/materials which (in)formally define and explain RCU consistency guarantees? I know there are some consistency models in the database area (such as PRAM, Read Uncommitted, etc) from https://jepsen.io/consistency and [1]. How does RCU related to those consistency models? I also found some comments online (One key distinction is that both MVCC and RLU provide much stronger consistency guarantees to readers than does RCU ...) (https://lwn.net/Articles/777036/). I do not understand how we reason/dresibe/compare the consistency guarantees. ( I even do not know what consistency guarantees provided by RCU formally) Could someone explain this to me? [1] Bailis, P., Davidson, A., Fekete, A., Ghodsi, A., Hellerstein, J. M., & Stoica, I. (2013). Highly available transactions: Virtues and limitations. Proceedings of the VLDB Endowment, 7(3), 181-192. Thanks Yuxin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.desnoyers at efficios.com Fri Dec 6 10:59:05 2019 From: mathieu.desnoyers at efficios.com (Mathieu Desnoyers) Date: Fri, 6 Dec 2019 10:59:05 -0500 (EST) Subject: [lttng-dev] RCU consistency guarantees In-Reply-To: References: <194534011.751.1575629349181.JavaMail.zimbra@efficios.com> Message-ID: <512711764.1078.1575647945136.JavaMail.zimbra@efficios.com> ----- On Dec 6, 2019, at 3:51 PM, Yuxin Ren wrote: > On Fri, Dec 6, 2019 at 5:49 AM Mathieu Desnoyers < [ > mailto:mathieu.desnoyers at efficios.com | mathieu.desnoyers at efficios.com ] > > wrote: >> ----- On Dec 5, 2019, at 8:17 PM, Yuxin Ren < [ mailto:ryx at gwmail.gwu.edu | >> ryx at gwmail.gwu.edu ] > wrote: >>> Hi, >>> I am a student, and learning RCU now, but still know very little about it. >>> Are there any documents/papers/materials which (in)formally define and explain >>> RCU consistency guarantees? >> You may want to have a look at >> User-Level Implementations of Read-Copy Update >> Article in IEEE Transactions on Parallel and Distributed Systems 23(2):375 - 382 >> ? March 2012 > Thanks for your info. > However, I do not think URCU talks about any consistency model formally. > From previous communication with Paul, he said RCU is not designed for > linearizability, and it is totally acceptable that RCU is not linearizable. > However, I am curious how to accurately/formally Characterize RCU consistency > model/guarantees Adding Paul E. McKenney in CC. I am referring to the section "Overview of RCU semantics" in the paper. Not sure it has the level of formality you are looking for though. Paul, do you have pointers to additional material ? Thanks, Mathieu >> as a starting point. >> Thanks, >> Mathieu >>> I know there are some consistency models in the database area (such as PRAM, >>> Read Uncommitted, etc) from [ https://jepsen.io/consistency | >>> https://jepsen.io/consistency ] and [1]. >>> How does RCU related to those consistency models? >>> I also found some comments online (One key distinction is that both MVCC and RLU >>> provide much stronger consistency guarantees to readers than does RCU ...) ( [ >>> https://lwn.net/Articles/777036/ | https://lwn.net/Articles/777036/ ] ). >>> I do not understand how we reason/dresibe/compare the consistency guarantees. ( >>> I even do not know what consistency guarantees provided by RCU formally) >>> Could someone explain this to me? >>> [1] Bailis, P., Davidson, A., Fekete, A., Ghodsi, A., Hellerstein, J. M., & >>> Stoica, I. (2013). Highly available transactions: Virtues and limitations. >>> Proceedings of the VLDB Endowment, 7(3), 181-192. >>> Thanks >>> Yuxin >>> _______________________________________________ >>> lttng-dev mailing list >>> [ mailto:lttng-dev at lists.lttng.org | lttng-dev at lists.lttng.org ] >>> [ https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev | >>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ] >> -- >> Mathieu Desnoyers >> EfficiOS Inc. >> [ http://www.efficios.com/ | http://www.efficios.com ] -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From paulmck at kernel.org Fri Dec 6 11:30:52 2019 From: paulmck at kernel.org (Paul E. McKenney) Date: Fri, 6 Dec 2019 08:30:52 -0800 Subject: [lttng-dev] RCU consistency guarantees In-Reply-To: <512711764.1078.1575647945136.JavaMail.zimbra@efficios.com> References: <194534011.751.1575629349181.JavaMail.zimbra@efficios.com> <512711764.1078.1575647945136.JavaMail.zimbra@efficios.com> Message-ID: <20191206163052.GG2889@paulmck-ThinkPad-P72> On Fri, Dec 06, 2019 at 10:59:05AM -0500, Mathieu Desnoyers wrote: > ----- On Dec 6, 2019, at 3:51 PM, Yuxin Ren wrote: > > > On Fri, Dec 6, 2019 at 5:49 AM Mathieu Desnoyers < [ > > mailto:mathieu.desnoyers at efficios.com | mathieu.desnoyers at efficios.com ] > > > wrote: > > >> ----- On Dec 5, 2019, at 8:17 PM, Yuxin Ren < [ mailto:ryx at gwmail.gwu.edu | > >> ryx at gwmail.gwu.edu ] > wrote: > > >>> Hi, > >>> I am a student, and learning RCU now, but still know very little about it. > >>> Are there any documents/papers/materials which (in)formally define and explain > >>> RCU consistency guarantees? > > >> You may want to have a look at > > >> User-Level Implementations of Read-Copy Update > >> Article in IEEE Transactions on Parallel and Distributed Systems 23(2):375 - 382 > >> ? March 2012 > > > Thanks for your info. > > However, I do not think URCU talks about any consistency model formally. > > > From previous communication with Paul, he said RCU is not designed for > > linearizability, and it is totally acceptable that RCU is not linearizable. > > However, I am curious how to accurately/formally Characterize RCU consistency > > model/guarantees > > Adding Paul E. McKenney in CC. > > I am referring to the section "Overview of RCU semantics" in the paper. Not sure it has the level of > formality you are looking for though. Paul, do you have pointers to additional material ? Indeed I do! The Linux kernel memory model (LKMM) includes RCU. It is in tools/memory-model in recent kernel source trees, which includes documentation. This is an executable model, which means that you can create litmus tests and have the model formally and automatically evaluate them. There are also a number of publications covering LKMM: o A formal kernel memory-ordering model https://lwn.net/Articles/718628/ https://lwn.net/Articles/720550/ These cover the release stores and dependency ordering that provide RCU's publish-subscribe guarantees. Backup material here: https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/ With these two likely being of particular interest: https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/RCUguarantees.html https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/srcu.html o Frightening Small Children and Disconcerting Grown-ups: Concurrency in the Linux Kernel https://dl.acm.org/citation.cfm?id=3177156 http://www0.cs.ucl.ac.uk/staff/j.alglave/papers/asplos18.pdf Backup material: http://diy.inria.fr/linux/ o Who's afraid of a big bad optimizing compiler? https://lwn.net/Articles/793253/ o Calibrating your fear of big bad optimizing compilers https://lwn.net/Articles/799218/ These last two justify use of normal C-language assignment statements to initialize and access data referenced by RCU-protected pointers. There is a large body of litmus tests (thousands of them) here: https://github.com/paulmckrcu/litmus Many of these litmus tests involve RCU, and these can be located by search for files containing rcu_read_lock(), rcu_read_unlock(), synchronize_rcu(), and so on. Or were you looking for something else? Thanx, Paul > Thanks, > > Mathieu > > >> as a starting point. > > >> Thanks, > > >> Mathieu > > >>> I know there are some consistency models in the database area (such as PRAM, > >>> Read Uncommitted, etc) from [ https://jepsen.io/consistency | > >>> https://jepsen.io/consistency ] and [1]. > >>> How does RCU related to those consistency models? > > >>> I also found some comments online (One key distinction is that both MVCC and RLU > >>> provide much stronger consistency guarantees to readers than does RCU ...) ( [ > >>> https://lwn.net/Articles/777036/ | https://lwn.net/Articles/777036/ ] ). > >>> I do not understand how we reason/dresibe/compare the consistency guarantees. ( > >>> I even do not know what consistency guarantees provided by RCU formally) > >>> Could someone explain this to me? > > >>> [1] Bailis, P., Davidson, A., Fekete, A., Ghodsi, A., Hellerstein, J. M., & > >>> Stoica, I. (2013). Highly available transactions: Virtues and limitations. > >>> Proceedings of the VLDB Endowment, 7(3), 181-192. > > >>> Thanks > >>> Yuxin > > >>> _______________________________________________ > >>> lttng-dev mailing list > >>> [ mailto:lttng-dev at lists.lttng.org | lttng-dev at lists.lttng.org ] > >>> [ https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev | > >>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ] > > >> -- > >> Mathieu Desnoyers > >> EfficiOS Inc. > >> [ http://www.efficios.com/ | http://www.efficios.com ] > > -- > Mathieu Desnoyers > EfficiOS Inc. > http://www.efficios.com From ryx at gwmail.gwu.edu Fri Dec 6 19:00:13 2019 From: ryx at gwmail.gwu.edu (Yuxin Ren) Date: Fri, 6 Dec 2019 19:00:13 -0500 Subject: [lttng-dev] RCU consistency guarantees In-Reply-To: <20191206163052.GG2889@paulmck-ThinkPad-P72> References: <194534011.751.1575629349181.JavaMail.zimbra@efficios.com> <512711764.1078.1575647945136.JavaMail.zimbra@efficios.com> <20191206163052.GG2889@paulmck-ThinkPad-P72> Message-ID: Thanks so much for your great help. I definitely will look at those resources and papers! One more thing that I am confused As I mentioned earlier, someone said One key distinction is that both MVCC and RLU provide much stronger consistency guarantees to readers than does RCU ...) (https://lwn.net/Articles/777036/). I am not sure if the above statement is correct or not. But in general, How can we compare RCU consistency guarantees to other techniques (such as RLU)? How to reason about which one has stronger or weaker guarantees? Thanks Yuxin On Fri, Dec 6, 2019 at 11:30 AM Paul E. McKenney wrote: > On Fri, Dec 06, 2019 at 10:59:05AM -0500, Mathieu Desnoyers wrote: > > ----- On Dec 6, 2019, at 3:51 PM, Yuxin Ren wrote: > > > > > On Fri, Dec 6, 2019 at 5:49 AM Mathieu Desnoyers < [ > > > mailto:mathieu.desnoyers at efficios.com | mathieu.desnoyers at efficios.com > ] > > > > wrote: > > > > >> ----- On Dec 5, 2019, at 8:17 PM, Yuxin Ren < [ mailto: > ryx at gwmail.gwu.edu | > > >> ryx at gwmail.gwu.edu ] > wrote: > > > > >>> Hi, > > >>> I am a student, and learning RCU now, but still know very little > about it. > > >>> Are there any documents/papers/materials which (in)formally define > and explain > > >>> RCU consistency guarantees? > > > > >> You may want to have a look at > > > > >> User-Level Implementations of Read-Copy Update > > >> Article in IEEE Transactions on Parallel and Distributed Systems > 23(2):375 - 382 > > >> ? March 2012 > > > > > Thanks for your info. > > > However, I do not think URCU talks about any consistency model > formally. > > > > > From previous communication with Paul, he said RCU is not designed for > > > linearizability, and it is totally acceptable that RCU is not > linearizable. > > > However, I am curious how to accurately/formally Characterize RCU > consistency > > > model/guarantees > > > > Adding Paul E. McKenney in CC. > > > > I am referring to the section "Overview of RCU semantics" in the paper. > Not sure it has the level of > > formality you are looking for though. Paul, do you have pointers to > additional material ? > > Indeed I do! The Linux kernel memory model (LKMM) includes RCU. It is > in tools/memory-model in recent kernel source trees, which includes > documentation. This is an executable model, which means that you > can create litmus tests and have the model formally and automatically > evaluate them. > > There are also a number of publications covering LKMM: > > o A formal kernel memory-ordering model > https://lwn.net/Articles/718628/ > https://lwn.net/Articles/720550/ > > These cover the release stores and dependency ordering that > provide RCU's publish-subscribe guarantees. > > Backup material here: > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/ > > With these two likely being of particular interest: > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/RCUguarantees.html > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/srcu.html > > o Frightening Small Children and Disconcerting Grown-ups: > Concurrency in the Linux Kernel > https://dl.acm.org/citation.cfm?id=3177156 > http://www0.cs.ucl.ac.uk/staff/j.alglave/papers/asplos18.pdf > > Backup material: > > http://diy.inria.fr/linux/ > > o Who's afraid of a big bad optimizing compiler? > https://lwn.net/Articles/793253/ > > o Calibrating your fear of big bad optimizing compilers > https://lwn.net/Articles/799218/ > > These last two justify use of normal C-language assignment > statements to initialize and access data referenced by > RCU-protected pointers. > > There is a large body of litmus tests (thousands of them) here: > > https://github.com/paulmckrcu/litmus > > Many of these litmus tests involve RCU, and these can be located by > search for files containing rcu_read_lock(), rcu_read_unlock(), > synchronize_rcu(), and so on. > > Or were you looking for something else? > > Thanx, Paul > > > Thanks, > > > > Mathieu > > > > >> as a starting point. > > > > >> Thanks, > > > > >> Mathieu > > > > >>> I know there are some consistency models in the database area (such > as PRAM, > > >>> Read Uncommitted, etc) from [ https://jepsen.io/consistency | > > >>> https://jepsen.io/consistency ] and [1]. > > >>> How does RCU related to those consistency models? > > > > >>> I also found some comments online (One key distinction is that both > MVCC and RLU > > >>> provide much stronger consistency guarantees to readers than does > RCU ...) ( [ > > >>> https://lwn.net/Articles/777036/ | https://lwn.net/Articles/777036/ > ] ). > > >>> I do not understand how we reason/dresibe/compare the consistency > guarantees. ( > > >>> I even do not know what consistency guarantees provided by RCU > formally) > > >>> Could someone explain this to me? > > > > >>> [1] Bailis, P., Davidson, A., Fekete, A., Ghodsi, A., Hellerstein, > J. M., & > > >>> Stoica, I. (2013). Highly available transactions: Virtues and > limitations. > > >>> Proceedings of the VLDB Endowment, 7(3), 181-192. > > > > >>> Thanks > > >>> Yuxin > > > > >>> _______________________________________________ > > >>> lttng-dev mailing list > > >>> [ mailto:lttng-dev at lists.lttng.org | lttng-dev at lists.lttng.org ] > > >>> [ https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev | > > >>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ] > > > > >> -- > > >> Mathieu Desnoyers > > >> EfficiOS Inc. > > >> [ http://www.efficios.com/ | http://www.efficios.com ] > > > > -- > > Mathieu Desnoyers > > EfficiOS Inc. > > http://www.efficios.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryx at gwmail.gwu.edu Sat Dec 7 15:04:42 2019 From: ryx at gwmail.gwu.edu (Yuxin Ren) Date: Sat, 7 Dec 2019 15:04:42 -0500 Subject: [lttng-dev] RCU consistency guarantees In-Reply-To: <20191207063730.GN2889@paulmck-ThinkPad-P72> References: <194534011.751.1575629349181.JavaMail.zimbra@efficios.com> <512711764.1078.1575647945136.JavaMail.zimbra@efficios.com> <20191206163052.GG2889@paulmck-ThinkPad-P72> <20191207063730.GN2889@paulmck-ThinkPad-P72> Message-ID: Thanks a lot for your help. I have some questions below. On Sat, Dec 7, 2019 at 1:37 AM Paul E. McKenney wrote: > On Fri, Dec 06, 2019 at 07:00:13PM -0500, Yuxin Ren wrote: > > Thanks so much for your great help. > > I definitely will look at those resources and papers! > > > > One more thing that I am confused > > As I mentioned earlier, someone said One key distinction is that both > MVCC > > and RLU provide much stronger consistency guarantees to readers than does > > RCU ...) (https://lwn.net/Articles/777036/). > > That someone was in fact me. ;-) > > > I am not sure if the above statement is correct or not. But in general, > > How can we compare RCU consistency guarantees to other techniques (such > as > > RLU)? > > How to reason about which one has stronger or weaker guarantees? > > I suggest starting from the use case. For concreteness, let's assume > that we are using a hash table. At one extreme, imagine a use case in > which each event makes exactly one hash-table operation. No information > is carried from one event to the next. (This might well be the case > for simple web server.) Such a use case cannot tell the difference > between RCU on the one hand and MVCC/RLU on the other. > > At the other extreme, suppose that each event either accesses or updates > multiple entries in the hash table. In this case, MVCC/RLU will rule > out outcomes that RCU would permit. For example, suppose we had four > events accessing two different elements in different buckets of the > hash table: > > E1: Adds 32 to the hash table. > E2: Adds 1729 to the hash table. > E3: Within a read-side critical section, looks up 32 then 1729. > E4: Within a read-side critical section, looks up 1729 then 32. > > Given either MVCC or RLU, it will not be possible for E3 to find 32 but > not 1729 and at the same time for E4 to find 1729 but not 32. Given RCU, > this outcome is possible. > When you say "Within a read-side section", do you mean within a single same read section? such as > read_lock() > lookup(32) > lookup(1729) > read_unlock() How about putting two lookups into two read-side sections? Do we still have the problem, then? > read_lock() > lookup(32) > read_unlock() > read_lock() > lookup(1729) > read_unlock() Could you kindly give me more clues why RCU can see such reorder, while RLU can prevent it? > This is because MVCC and RLU provide readers a consistent view of > the updates, and RCU does not. Of course, it is often the case that a > consistent view is not needed, in which case the MVCC and RLU guarantees > are incurring read-side overhead for no reason. But if the use case > requires consistent readers, RCU is not an option. > > The reason a consistent view is not always needed is that speed-of-light > delays make it impossible to provide a consistent view of the outside > world. In the common case where the use case interacts with the > outside world, the algorithms absolutely must be designed to tolerate > inconsistency, which opens the door to things like RCU. > I am confused here. I think speed-of-light delays happen everywhere, not only bound to RCU, but also any other synchronization approach (such RLU). If so, how do others (RLU) provide consistent views? Thanks for your education. Yuxin > > Thanx, Paul > > > Thanks > > Yuxin > > > > On Fri, Dec 6, 2019 at 11:30 AM Paul E. McKenney > wrote: > > > > > On Fri, Dec 06, 2019 at 10:59:05AM -0500, Mathieu Desnoyers wrote: > > > > ----- On Dec 6, 2019, at 3:51 PM, Yuxin Ren > wrote: > > > > > > > > > On Fri, Dec 6, 2019 at 5:49 AM Mathieu Desnoyers < [ > > > > > mailto:mathieu.desnoyers at efficios.com | > mathieu.desnoyers at efficios.com > > > ] > > > > > > wrote: > > > > > > > > >> ----- On Dec 5, 2019, at 8:17 PM, Yuxin Ren < [ mailto: > > > ryx at gwmail.gwu.edu | > > > > >> ryx at gwmail.gwu.edu ] > wrote: > > > > > > > > >>> Hi, > > > > >>> I am a student, and learning RCU now, but still know very little > > > about it. > > > > >>> Are there any documents/papers/materials which (in)formally > define > > > and explain > > > > >>> RCU consistency guarantees? > > > > > > > > >> You may want to have a look at > > > > > > > > >> User-Level Implementations of Read-Copy Update > > > > >> Article in IEEE Transactions on Parallel and Distributed Systems > > > 23(2):375 - 382 > > > > >> ? March 2012 > > > > > > > > > Thanks for your info. > > > > > However, I do not think URCU talks about any consistency model > > > formally. > > > > > > > > > From previous communication with Paul, he said RCU is not designed > for > > > > > linearizability, and it is totally acceptable that RCU is not > > > linearizable. > > > > > However, I am curious how to accurately/formally Characterize RCU > > > consistency > > > > > model/guarantees > > > > > > > > Adding Paul E. McKenney in CC. > > > > > > > > I am referring to the section "Overview of RCU semantics" in the > paper. > > > Not sure it has the level of > > > > formality you are looking for though. Paul, do you have pointers to > > > additional material ? > > > > > > Indeed I do! The Linux kernel memory model (LKMM) includes RCU. It is > > > in tools/memory-model in recent kernel source trees, which includes > > > documentation. This is an executable model, which means that you > > > can create litmus tests and have the model formally and automatically > > > evaluate them. > > > > > > There are also a number of publications covering LKMM: > > > > > > o A formal kernel memory-ordering model > > > https://lwn.net/Articles/718628/ > > > https://lwn.net/Articles/720550/ > > > > > > These cover the release stores and dependency ordering that > > > provide RCU's publish-subscribe guarantees. > > > > > > Backup material here: > > > > > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/ > > > > > > With these two likely being of particular interest: > > > > > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/RCUguarantees.html > > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/srcu.html > > > > > > o Frightening Small Children and Disconcerting Grown-ups: > > > Concurrency in the Linux Kernel > > > https://dl.acm.org/citation.cfm?id=3177156 > > > http://www0.cs.ucl.ac.uk/staff/j.alglave/papers/asplos18.pdf > > > > > > Backup material: > > > > > > http://diy.inria.fr/linux/ > > > > > > o Who's afraid of a big bad optimizing compiler? > > > https://lwn.net/Articles/793253/ > > > > > > o Calibrating your fear of big bad optimizing compilers > > > https://lwn.net/Articles/799218/ > > > > > > These last two justify use of normal C-language assignment > > > statements to initialize and access data referenced by > > > RCU-protected pointers. > > > > > > There is a large body of litmus tests (thousands of them) here: > > > > > > https://github.com/paulmckrcu/litmus > > > > > > Many of these litmus tests involve RCU, and these can be located by > > > search for files containing rcu_read_lock(), rcu_read_unlock(), > > > synchronize_rcu(), and so on. > > > > > > Or were you looking for something else? > > > > > > Thanx, Paul > > > > > > > Thanks, > > > > > > > > Mathieu > > > > > > > > >> as a starting point. > > > > > > > > >> Thanks, > > > > > > > > >> Mathieu > > > > > > > > >>> I know there are some consistency models in the database area > (such > > > as PRAM, > > > > >>> Read Uncommitted, etc) from [ https://jepsen.io/consistency | > > > > >>> https://jepsen.io/consistency ] and [1]. > > > > >>> How does RCU related to those consistency models? > > > > > > > > >>> I also found some comments online (One key distinction is that > both > > > MVCC and RLU > > > > >>> provide much stronger consistency guarantees to readers than does > > > RCU ...) ( [ > > > > >>> https://lwn.net/Articles/777036/ | > https://lwn.net/Articles/777036/ > > > ] ). > > > > >>> I do not understand how we reason/dresibe/compare the consistency > > > guarantees. ( > > > > >>> I even do not know what consistency guarantees provided by RCU > > > formally) > > > > >>> Could someone explain this to me? > > > > > > > > >>> [1] Bailis, P., Davidson, A., Fekete, A., Ghodsi, A., > Hellerstein, > > > J. M., & > > > > >>> Stoica, I. (2013). Highly available transactions: Virtues and > > > limitations. > > > > >>> Proceedings of the VLDB Endowment, 7(3), 181-192. > > > > > > > > >>> Thanks > > > > >>> Yuxin > > > > > > > > >>> _______________________________________________ > > > > >>> lttng-dev mailing list > > > > >>> [ mailto:lttng-dev at lists.lttng.org | lttng-dev at lists.lttng.org ] > > > > >>> [ https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev | > > > > >>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ] > > > > > > > > >> -- > > > > >> Mathieu Desnoyers > > > > >> EfficiOS Inc. > > > > >> [ http://www.efficios.com/ | http://www.efficios.com ] > > > > > > > > -- > > > > Mathieu Desnoyers > > > > EfficiOS Inc. > > > > http://www.efficios.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paulmck at kernel.org Sat Dec 7 01:37:30 2019 From: paulmck at kernel.org (Paul E. McKenney) Date: Fri, 6 Dec 2019 22:37:30 -0800 Subject: [lttng-dev] RCU consistency guarantees In-Reply-To: References: <194534011.751.1575629349181.JavaMail.zimbra@efficios.com> <512711764.1078.1575647945136.JavaMail.zimbra@efficios.com> <20191206163052.GG2889@paulmck-ThinkPad-P72> Message-ID: <20191207063730.GN2889@paulmck-ThinkPad-P72> On Fri, Dec 06, 2019 at 07:00:13PM -0500, Yuxin Ren wrote: > Thanks so much for your great help. > I definitely will look at those resources and papers! > > One more thing that I am confused > As I mentioned earlier, someone said One key distinction is that both MVCC > and RLU provide much stronger consistency guarantees to readers than does > RCU ...) (https://lwn.net/Articles/777036/). That someone was in fact me. ;-) > I am not sure if the above statement is correct or not. But in general, > How can we compare RCU consistency guarantees to other techniques (such as > RLU)? > How to reason about which one has stronger or weaker guarantees? I suggest starting from the use case. For concreteness, let's assume that we are using a hash table. At one extreme, imagine a use case in which each event makes exactly one hash-table operation. No information is carried from one event to the next. (This might well be the case for simple web server.) Such a use case cannot tell the difference between RCU on the one hand and MVCC/RLU on the other. At the other extreme, suppose that each event either accesses or updates multiple entries in the hash table. In this case, MVCC/RLU will rule out outcomes that RCU would permit. For example, suppose we had four events accessing two different elements in different buckets of the hash table: E1: Adds 32 to the hash table. E2: Adds 1729 to the hash table. E3: Within a read-side critical section, looks up 32 then 1729. E4: Within a read-side critical section, looks up 1729 then 32. Given either MVCC or RLU, it will not be possible for E3 to find 32 but not 1729 and at the same time for E4 to find 1729 but not 32. Given RCU, this outcome is possible. This is because MVCC and RLU provide readers a consistent view of the updates, and RCU does not. Of course, it is often the case that a consistent view is not needed, in which case the MVCC and RLU guarantees are incurring read-side overhead for no reason. But if the use case requires consistent readers, RCU is not an option. The reason a consistent view is not always needed is that speed-of-light delays make it impossible to provide a consistent view of the outside world. In the common case where the use case interacts with the outside world, the algorithms absolutely must be designed to tolerate inconsistency, which opens the door to things like RCU. Thanx, Paul > Thanks > Yuxin > > On Fri, Dec 6, 2019 at 11:30 AM Paul E. McKenney wrote: > > > On Fri, Dec 06, 2019 at 10:59:05AM -0500, Mathieu Desnoyers wrote: > > > ----- On Dec 6, 2019, at 3:51 PM, Yuxin Ren wrote: > > > > > > > On Fri, Dec 6, 2019 at 5:49 AM Mathieu Desnoyers < [ > > > > mailto:mathieu.desnoyers at efficios.com | mathieu.desnoyers at efficios.com > > ] > > > > > wrote: > > > > > > >> ----- On Dec 5, 2019, at 8:17 PM, Yuxin Ren < [ mailto: > > ryx at gwmail.gwu.edu | > > > >> ryx at gwmail.gwu.edu ] > wrote: > > > > > > >>> Hi, > > > >>> I am a student, and learning RCU now, but still know very little > > about it. > > > >>> Are there any documents/papers/materials which (in)formally define > > and explain > > > >>> RCU consistency guarantees? > > > > > > >> You may want to have a look at > > > > > > >> User-Level Implementations of Read-Copy Update > > > >> Article in IEEE Transactions on Parallel and Distributed Systems > > 23(2):375 - 382 > > > >> ? March 2012 > > > > > > > Thanks for your info. > > > > However, I do not think URCU talks about any consistency model > > formally. > > > > > > > From previous communication with Paul, he said RCU is not designed for > > > > linearizability, and it is totally acceptable that RCU is not > > linearizable. > > > > However, I am curious how to accurately/formally Characterize RCU > > consistency > > > > model/guarantees > > > > > > Adding Paul E. McKenney in CC. > > > > > > I am referring to the section "Overview of RCU semantics" in the paper. > > Not sure it has the level of > > > formality you are looking for though. Paul, do you have pointers to > > additional material ? > > > > Indeed I do! The Linux kernel memory model (LKMM) includes RCU. It is > > in tools/memory-model in recent kernel source trees, which includes > > documentation. This is an executable model, which means that you > > can create litmus tests and have the model formally and automatically > > evaluate them. > > > > There are also a number of publications covering LKMM: > > > > o A formal kernel memory-ordering model > > https://lwn.net/Articles/718628/ > > https://lwn.net/Articles/720550/ > > > > These cover the release stores and dependency ordering that > > provide RCU's publish-subscribe guarantees. > > > > Backup material here: > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/ > > > > With these two likely being of particular interest: > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/RCUguarantees.html > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/srcu.html > > > > o Frightening Small Children and Disconcerting Grown-ups: > > Concurrency in the Linux Kernel > > https://dl.acm.org/citation.cfm?id=3177156 > > http://www0.cs.ucl.ac.uk/staff/j.alglave/papers/asplos18.pdf > > > > Backup material: > > > > http://diy.inria.fr/linux/ > > > > o Who's afraid of a big bad optimizing compiler? > > https://lwn.net/Articles/793253/ > > > > o Calibrating your fear of big bad optimizing compilers > > https://lwn.net/Articles/799218/ > > > > These last two justify use of normal C-language assignment > > statements to initialize and access data referenced by > > RCU-protected pointers. > > > > There is a large body of litmus tests (thousands of them) here: > > > > https://github.com/paulmckrcu/litmus > > > > Many of these litmus tests involve RCU, and these can be located by > > search for files containing rcu_read_lock(), rcu_read_unlock(), > > synchronize_rcu(), and so on. > > > > Or were you looking for something else? > > > > Thanx, Paul > > > > > Thanks, > > > > > > Mathieu > > > > > > >> as a starting point. > > > > > > >> Thanks, > > > > > > >> Mathieu > > > > > > >>> I know there are some consistency models in the database area (such > > as PRAM, > > > >>> Read Uncommitted, etc) from [ https://jepsen.io/consistency | > > > >>> https://jepsen.io/consistency ] and [1]. > > > >>> How does RCU related to those consistency models? > > > > > > >>> I also found some comments online (One key distinction is that both > > MVCC and RLU > > > >>> provide much stronger consistency guarantees to readers than does > > RCU ...) ( [ > > > >>> https://lwn.net/Articles/777036/ | https://lwn.net/Articles/777036/ > > ] ). > > > >>> I do not understand how we reason/dresibe/compare the consistency > > guarantees. ( > > > >>> I even do not know what consistency guarantees provided by RCU > > formally) > > > >>> Could someone explain this to me? > > > > > > >>> [1] Bailis, P., Davidson, A., Fekete, A., Ghodsi, A., Hellerstein, > > J. M., & > > > >>> Stoica, I. (2013). Highly available transactions: Virtues and > > limitations. > > > >>> Proceedings of the VLDB Endowment, 7(3), 181-192. > > > > > > >>> Thanks > > > >>> Yuxin > > > > > > >>> _______________________________________________ > > > >>> lttng-dev mailing list > > > >>> [ mailto:lttng-dev at lists.lttng.org | lttng-dev at lists.lttng.org ] > > > >>> [ https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev | > > > >>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ] > > > > > > >> -- > > > >> Mathieu Desnoyers > > > >> EfficiOS Inc. > > > >> [ http://www.efficios.com/ | http://www.efficios.com ] > > > > > > -- > > > Mathieu Desnoyers > > > EfficiOS Inc. > > > http://www.efficios.com > > From paulmck at kernel.org Sat Dec 7 17:42:32 2019 From: paulmck at kernel.org (Paul E. McKenney) Date: Sat, 7 Dec 2019 14:42:32 -0800 Subject: [lttng-dev] RCU consistency guarantees In-Reply-To: References: <194534011.751.1575629349181.JavaMail.zimbra@efficios.com> <512711764.1078.1575647945136.JavaMail.zimbra@efficios.com> <20191206163052.GG2889@paulmck-ThinkPad-P72> <20191207063730.GN2889@paulmck-ThinkPad-P72> Message-ID: <20191207224232.GR2889@paulmck-ThinkPad-P72> On Sat, Dec 07, 2019 at 03:04:42PM -0500, Yuxin Ren wrote: > Thanks a lot for your help. I have some questions below. > > On Sat, Dec 7, 2019 at 1:37 AM Paul E. McKenney wrote: > > > On Fri, Dec 06, 2019 at 07:00:13PM -0500, Yuxin Ren wrote: > > > Thanks so much for your great help. > > > I definitely will look at those resources and papers! > > > > > > One more thing that I am confused > > > As I mentioned earlier, someone said One key distinction is that both > > MVCC > > > and RLU provide much stronger consistency guarantees to readers than does > > > RCU ...) (https://lwn.net/Articles/777036/). > > > > That someone was in fact me. ;-) > > > > > I am not sure if the above statement is correct or not. But in general, > > > How can we compare RCU consistency guarantees to other techniques (such > > as > > > RLU)? > > > How to reason about which one has stronger or weaker guarantees? > > > > I suggest starting from the use case. For concreteness, let's assume > > that we are using a hash table. At one extreme, imagine a use case in > > which each event makes exactly one hash-table operation. No information > > is carried from one event to the next. (This might well be the case > > for simple web server.) Such a use case cannot tell the difference > > between RCU on the one hand and MVCC/RLU on the other. > > > > At the other extreme, suppose that each event either accesses or updates > > multiple entries in the hash table. In this case, MVCC/RLU will rule > > out outcomes that RCU would permit. For example, suppose we had four > > events accessing two different elements in different buckets of the > > hash table: > > > > E1: Adds 32 to the hash table. > > E2: Adds 1729 to the hash table. > > E3: Within a read-side critical section, looks up 32 then 1729. > > E4: Within a read-side critical section, looks up 1729 then 32. > > > > Given either MVCC or RLU, it will not be possible for E3 to find 32 but > > not 1729 and at the same time for E4 to find 1729 but not 32. Given RCU, > > this outcome is possible. > > > When you say "Within a read-side section", do you mean within a single same > read section? such as > > > read_lock() > > lookup(32) > > lookup(1729) > > read_unlock() > > > How about putting two lookups into two read-side sections? Do we still have > the problem, then? > > > read_lock() > > lookup(32) > > read_unlock() > > read_lock() > > lookup(1729) > > read_unlock() Without in any way agreeing with your characterization of this as a problem, because rcu_read_lock() and rcu_read_unlock() provide absolutely no ordering guarantees in the absence of a grace period, any non-grace-period-related reordering that can happen with a single RCU read-side critical section can also happen when that critical section is split in two as you have done above. > Could you kindly give me more clues why RCU can see such reorder, while RLU > can prevent it? Here are minimal C-language implementations for RCU that can (and are) actually used: #define rcu_read_lock() #define rcu_read_unlock() Please compare these to the read-side markers presented in the RLU paper, and then tell me your thoughts on the answer to your question. ;-) > > This is because MVCC and RLU provide readers a consistent view of > > the updates, and RCU does not. Of course, it is often the case that a > > consistent view is not needed, in which case the MVCC and RLU guarantees > > are incurring read-side overhead for no reason. But if the use case > > requires consistent readers, RCU is not an option. > > > > The reason a consistent view is not always needed is that speed-of-light > > delays make it impossible to provide a consistent view of the outside > > world. In the common case where the use case interacts with the > > outside world, the algorithms absolutely must be designed to tolerate > > inconsistency, which opens the door to things like RCU. > > I am confused here. I think speed-of-light delays happen everywhere, not > only bound to RCU, but also any other synchronization approach (such RLU). > If so, how do others (RLU) provide consistent views? You just stated the answer. Now it is only necessary for you to invest the time, effort, and thought to fully understand it. To help with this, the following paragraph provides another hint: Yes, you are quite right, speed-of-light delays between the outside world and the computer affect RLU just as surely as they do RCU. This means that the additional consistency guarantees provided by RLU must necessarily be limited to the confines of the computer system in question. Taking this one step further, there are also speed-of-light delays within the computer. Therefore, in the general case, RLU can provide its consistency guarantees, even within the confines of the computer system, only at the expense of incurring delays. Because RCU does not provide RLU's consistency guarantees, it need not incur RLU's delays. This is not a new line of reasoning, see for example: @article{Herlihy:1996:LCN:1063369.1063372 ,author = {Herlihy, Maurice and Shavit, Nir and Waarts, Orli} ,title = {Linearizable counting networks} ,journal = {Distrib. Comput.} ,volume = {9} ,issue = {4} ,month = {February} ,year = {1996} ,issn = {0178-2770} ,pages = {193--203} ,numpages = {11} ,url = {http://portal.acm.org/citation.cfm?id=1063369.1063372} ,doi = {10.1007/s004460050019} ,acmid = {1063372} ,publisher = {Springer-Verlag} ,address = {London, UK} ,keywords = {concurrency, contention, counting networks, data structures, linearizability} } Thanx, Paul > Thanks for your education. > Yuxin > > > > > Thanx, Paul > > > > > Thanks > > > Yuxin > > > > > > On Fri, Dec 6, 2019 at 11:30 AM Paul E. McKenney > > wrote: > > > > > > > On Fri, Dec 06, 2019 at 10:59:05AM -0500, Mathieu Desnoyers wrote: > > > > > ----- On Dec 6, 2019, at 3:51 PM, Yuxin Ren > > wrote: > > > > > > > > > > > On Fri, Dec 6, 2019 at 5:49 AM Mathieu Desnoyers < [ > > > > > > mailto:mathieu.desnoyers at efficios.com | > > mathieu.desnoyers at efficios.com > > > > ] > > > > > > > wrote: > > > > > > > > > > >> ----- On Dec 5, 2019, at 8:17 PM, Yuxin Ren < [ mailto: > > > > ryx at gwmail.gwu.edu | > > > > > >> ryx at gwmail.gwu.edu ] > wrote: > > > > > > > > > > >>> Hi, > > > > > >>> I am a student, and learning RCU now, but still know very little > > > > about it. > > > > > >>> Are there any documents/papers/materials which (in)formally > > define > > > > and explain > > > > > >>> RCU consistency guarantees? > > > > > > > > > > >> You may want to have a look at > > > > > > > > > > >> User-Level Implementations of Read-Copy Update > > > > > >> Article in IEEE Transactions on Parallel and Distributed Systems > > > > 23(2):375 - 382 > > > > > >> ? March 2012 > > > > > > > > > > > Thanks for your info. > > > > > > However, I do not think URCU talks about any consistency model > > > > formally. > > > > > > > > > > > From previous communication with Paul, he said RCU is not designed > > for > > > > > > linearizability, and it is totally acceptable that RCU is not > > > > linearizable. > > > > > > However, I am curious how to accurately/formally Characterize RCU > > > > consistency > > > > > > model/guarantees > > > > > > > > > > Adding Paul E. McKenney in CC. > > > > > > > > > > I am referring to the section "Overview of RCU semantics" in the > > paper. > > > > Not sure it has the level of > > > > > formality you are looking for though. Paul, do you have pointers to > > > > additional material ? > > > > > > > > Indeed I do! The Linux kernel memory model (LKMM) includes RCU. It is > > > > in tools/memory-model in recent kernel source trees, which includes > > > > documentation. This is an executable model, which means that you > > > > can create litmus tests and have the model formally and automatically > > > > evaluate them. > > > > > > > > There are also a number of publications covering LKMM: > > > > > > > > o A formal kernel memory-ordering model > > > > https://lwn.net/Articles/718628/ > > > > https://lwn.net/Articles/720550/ > > > > > > > > These cover the release stores and dependency ordering that > > > > provide RCU's publish-subscribe guarantees. > > > > > > > > Backup material here: > > > > > > > > > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/ > > > > > > > > With these two likely being of particular interest: > > > > > > > > > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/RCUguarantees.html > > > > > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/srcu.html > > > > > > > > o Frightening Small Children and Disconcerting Grown-ups: > > > > Concurrency in the Linux Kernel > > > > https://dl.acm.org/citation.cfm?id=3177156 > > > > http://www0.cs.ucl.ac.uk/staff/j.alglave/papers/asplos18.pdf > > > > > > > > Backup material: > > > > > > > > http://diy.inria.fr/linux/ > > > > > > > > o Who's afraid of a big bad optimizing compiler? > > > > https://lwn.net/Articles/793253/ > > > > > > > > o Calibrating your fear of big bad optimizing compilers > > > > https://lwn.net/Articles/799218/ > > > > > > > > These last two justify use of normal C-language assignment > > > > statements to initialize and access data referenced by > > > > RCU-protected pointers. > > > > > > > > There is a large body of litmus tests (thousands of them) here: > > > > > > > > https://github.com/paulmckrcu/litmus > > > > > > > > Many of these litmus tests involve RCU, and these can be located by > > > > search for files containing rcu_read_lock(), rcu_read_unlock(), > > > > synchronize_rcu(), and so on. > > > > > > > > Or were you looking for something else? > > > > > > > > Thanx, Paul > > > > > > > > > Thanks, > > > > > > > > > > Mathieu > > > > > > > > > > >> as a starting point. > > > > > > > > > > >> Thanks, > > > > > > > > > > >> Mathieu > > > > > > > > > > >>> I know there are some consistency models in the database area > > (such > > > > as PRAM, > > > > > >>> Read Uncommitted, etc) from [ https://jepsen.io/consistency | > > > > > >>> https://jepsen.io/consistency ] and [1]. > > > > > >>> How does RCU related to those consistency models? > > > > > > > > > > >>> I also found some comments online (One key distinction is that > > both > > > > MVCC and RLU > > > > > >>> provide much stronger consistency guarantees to readers than does > > > > RCU ...) ( [ > > > > > >>> https://lwn.net/Articles/777036/ | > > https://lwn.net/Articles/777036/ > > > > ] ). > > > > > >>> I do not understand how we reason/dresibe/compare the consistency > > > > guarantees. ( > > > > > >>> I even do not know what consistency guarantees provided by RCU > > > > formally) > > > > > >>> Could someone explain this to me? > > > > > > > > > > >>> [1] Bailis, P., Davidson, A., Fekete, A., Ghodsi, A., > > Hellerstein, > > > > J. M., & > > > > > >>> Stoica, I. (2013). Highly available transactions: Virtues and > > > > limitations. > > > > > >>> Proceedings of the VLDB Endowment, 7(3), 181-192. > > > > > > > > > > >>> Thanks > > > > > >>> Yuxin > > > > > > > > > > >>> _______________________________________________ > > > > > >>> lttng-dev mailing list > > > > > >>> [ mailto:lttng-dev at lists.lttng.org | lttng-dev at lists.lttng.org ] > > > > > >>> [ https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev | > > > > > >>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ] > > > > > > > > > > >> -- > > > > > >> Mathieu Desnoyers > > > > > >> EfficiOS Inc. > > > > > >> [ http://www.efficios.com/ | http://www.efficios.com ] > > > > > > > > > > -- > > > > > Mathieu Desnoyers > > > > > EfficiOS Inc. > > > > > http://www.efficios.com > > > > > > From mjeanson at efficios.com Tue Dec 10 11:41:11 2019 From: mjeanson at efficios.com (Michael Jeanson) Date: Tue, 10 Dec 2019 11:41:11 -0500 Subject: [lttng-dev] [PATCH lttng-modules] fix: y2038: itimer: change implementation to timespec64 (v5.5) In-Reply-To: <20191210164114.26954-1-mjeanson@efficios.com> References: <20191210164114.26954-1-mjeanson@efficios.com> Message-ID: <20191210164114.26954-2-mjeanson@efficios.com> See upstream commit: commit bd40a175769d411b2a37e1c087082ac7ee2c15bb Author: Arnd Bergmann Date: Thu Nov 7 15:27:39 2019 +0100 y2038: itimer: change implementation to timespec64 There is no 64-bit version of getitimer/setitimer since that is not actually needed. However, the implementation is built around the deprecated 'struct timeval' type. Change the code to use timespec64 internally to reduce the dependencies on timeval and associated helper functions. Minor adjustments in the code are needed to make the native and compat version work the same way, and to keep the range check working after the conversion. Signed-off-by: Michael Jeanson --- instrumentation/events/lttng-module/timer.h | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/instrumentation/events/lttng-module/timer.h b/instrumentation/events/lttng-module/timer.h index 997084f..1a45d82 100644 --- a/instrumentation/events/lttng-module/timer.h +++ b/instrumentation/events/lttng-module/timer.h @@ -294,7 +294,26 @@ LTTNG_TRACEPOINT_EVENT_INSTANCE_MAP(timer_hrtimer_class, hrtimer_cancel, * zero, otherwise it is started * @expires: the itimers expiry time */ -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,11,0)) +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(5,5,0)) +LTTNG_TRACEPOINT_EVENT_MAP(itimer_state, + + timer_itimer_state, + + TP_PROTO(int which, const struct itimerspec64 *const value, + unsigned long long expires), + + TP_ARGS(which, value, expires), + + TP_FIELDS( + ctf_integer(int, which, which) + ctf_integer(unsigned long long, expires, expires) + ctf_integer(long, value_sec, value->it_value.tv_sec) + ctf_integer(long, value_nsec, value->it_value.tv_nsec) + ctf_integer(long, interval_sec, value->it_interval.tv_sec) + ctf_integer(long, interval_nsec, value->it_interval.tv_nsec) + ) +) +#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(4,11,0)) LTTNG_TRACEPOINT_EVENT_MAP(itimer_state, timer_itimer_state, -- 2.17.1 From mjeanson at efficios.com Tue Dec 10 11:41:10 2019 From: mjeanson at efficios.com (Michael Jeanson) Date: Tue, 10 Dec 2019 11:41:10 -0500 Subject: [lttng-dev] [PATCH lttng-modules] Update .gitignore from upstream Message-ID: <20191210164114.26954-1-mjeanson@efficios.com> Signed-off-by: Michael Jeanson --- .gitignore | 110 +++++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 89 insertions(+), 21 deletions(-) diff --git a/.gitignore b/.gitignore index 38e1684..4af69a2 100644 --- a/.gitignore +++ b/.gitignore @@ -7,30 +7,45 @@ # command after changing this file, to see if there are # any tracked files which get ignored after the change. # -# Normal rules +# Normal rules (sorted alphabetically) # .* +*.a +*.asn1.[ch] +*.bin +*.bz2 +*.c.[012]*.* +*.dt.yaml +*.dtb +*.dtb.S +*.dwo +*.elf +*.gcno +*.gz +*.i +*.ko +*.lex.c +*.ll +*.lst +*.lz4 +*.lzma +*.lzo +*.mod +*.mod.c *.o *.o.* -*.a +*.patch *.s -*.ko *.so *.so.dbg -*.mod.c -*.i -*.lst +*.su *.symtypes -*.order +*.tab.[ch] +*.tar +*.xz +Module.symvers modules.builtin -*.elf -*.bin -*.gz -*.bz2 -*.lzma -*.lzo -*.gcno -cscope.* +modules.order # # Top-level generic files @@ -39,25 +54,51 @@ cscope.* /TAGS /linux /vmlinux +/vmlinux.32 +/vmlinux-gdb.py /vmlinuz /System.map /Module.markers +/modules.builtin.modinfo +/modules.nsdeps -# ignore across tree -Module.symvers +# +# RPM spec file (make rpm-pkg) +# +/*.spec + +# +# Debian directory (make deb-pkg) +# +/debian/ + +# +# Snap directory (make snap-pkg) +# +/snap/ + +# +# tar directory (make tar*-pkg) +# +/tar-install/ # -# git files that we don't want to ignore even it they are dot-files +# We don't want to ignore the following even if they are dot-files # +!.clang-format +!.cocciconfig +!.get_maintainer.ignore +!.gitattributes !.gitignore !.mailmap # # Generated include files # -include/config -include/linux/version.h -include/generated +/include/config/ +/include/generated/ +/include/ksym/ +/arch/*/include/generated/ # stgit generated dirs patches-* @@ -76,8 +117,35 @@ GRTAGS GSYMS GTAGS +# id-utils files +ID + *.orig *~ \#*# +# +# Leavings from module signing +# +extra_certificates +signing_key.pem +signing_key.priv +signing_key.x509 +x509.genkey + +# Kconfig presets +/all.config +/alldef.config +/allmod.config +/allno.config +/allrandom.config +/allyes.config + +# Kdevelop4 +*.kdev4 + +# Clang's compilation database file +/compile_commands.json + +# lttng-modules specific /extra_version -- 2.17.1 From mjeanson at efficios.com Tue Dec 10 11:41:12 2019 From: mjeanson at efficios.com (Michael Jeanson) Date: Tue, 10 Dec 2019 11:41:12 -0500 Subject: [lttng-dev] [PATCH lttng-modules] fix: btrfs: tracepoints: constify all pointers (v5.5) In-Reply-To: <20191210164114.26954-1-mjeanson@efficios.com> References: <20191210164114.26954-1-mjeanson@efficios.com> Message-ID: <20191210164114.26954-3-mjeanson@efficios.com> See upstream commit: commit 1d2e7c7c3ed73cc510a4dc093df2a935092ff5ad Author: David Sterba Date: Thu Oct 17 13:28:57 2019 +0200 btrfs: tracepoints: constify all pointers We don't modify the data passed to tracepoints, some of the declarations are already const, add it to the rest. Signed-off-by: Michael Jeanson --- instrumentation/events/lttng-module/btrfs.h | 39 +++++++++++++++++++-- 1 file changed, 37 insertions(+), 2 deletions(-) diff --git a/instrumentation/events/lttng-module/btrfs.h b/instrumentation/events/lttng-module/btrfs.h index c548cf2..59b668c 100644 --- a/instrumentation/events/lttng-module/btrfs.h +++ b/instrumentation/events/lttng-module/btrfs.h @@ -286,7 +286,26 @@ LTTNG_TRACEPOINT_EVENT(btrfs_get_extent, #endif /* #else #if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,10,0)) */ -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,18,0)) +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(5,5,0)) +LTTNG_TRACEPOINT_EVENT(btrfs_handle_em_exist, + + TP_PROTO(const struct btrfs_fs_info *fs_info, + const struct extent_map *existing, const struct extent_map *map, + u64 start, u64 len), + + TP_ARGS(fs_info, existing, map, start, len), + + TP_FIELDS( + ctf_array(u8, fsid, lttng_fs_info_fsid, BTRFS_UUID_SIZE) + ctf_integer(u64, e_start, existing->start) + ctf_integer(u64, e_len, existing->len) + ctf_integer(u64, map_start, map->start) + ctf_integer(u64, map_len, map->len) + ctf_integer(u64, start, start) + ctf_integer(u64, len, len) + ) +) +#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(4,18,0)) LTTNG_TRACEPOINT_EVENT(btrfs_handle_em_exist, TP_PROTO(struct btrfs_fs_info *fs_info, @@ -1620,7 +1639,23 @@ LTTNG_TRACEPOINT_EVENT(btrfs_cow_block, ) #endif -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0) || \ +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(5,5,0)) +LTTNG_TRACEPOINT_EVENT(btrfs_space_reservation, + + TP_PROTO(const struct btrfs_fs_info *fs_info, const char *type, u64 val, + u64 bytes, int reserve), + + TP_ARGS(fs_info, type, val, bytes, reserve), + + TP_FIELDS( + ctf_array(u8, fsid, lttng_fs_info_fsid, BTRFS_UUID_SIZE) + ctf_string(type, type) + ctf_integer(u64, val, val) + ctf_integer(u64, bytes, bytes) + ctf_integer(int, reserve, reserve) + ) +) +#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0) || \ LTTNG_SLE_KERNEL_RANGE(4,4,73,5,0,0, 4,4,73,6,0,0) || \ LTTNG_SLE_KERNEL_RANGE(4,4,82,6,0,0, 4,4,82,7,0,0) || \ LTTNG_SLE_KERNEL_RANGE(4,4,92,6,0,0, 4,4,92,7,0,0) || \ -- 2.17.1 From mjeanson at efficios.com Tue Dec 10 11:41:14 2019 From: mjeanson at efficios.com (Michael Jeanson) Date: Tue, 10 Dec 2019 11:41:14 -0500 Subject: [lttng-dev] [PATCH lttng-modules] fix: ext4: Reserve revoke credits for freed blocks (v5.5) In-Reply-To: <20191210164114.26954-1-mjeanson@efficios.com> References: <20191210164114.26954-1-mjeanson@efficios.com> Message-ID: <20191210164114.26954-5-mjeanson@efficios.com> See upstream commit: commit 83448bdfb59731c2f54784ed3f4a93ff95be6e7e Author: Jan Kara Date: Tue Nov 5 17:44:29 2019 +0100 ext4: Reserve revoke credits for freed blocks So far we have reserved only relatively high fixed amount of revoke credits for each transaction. We over-reserved by large amount for most cases but when freeing large directories or files with data journalling, the fixed amount is not enough. In fact the worst case estimate is inconveniently large (maximum extent size) for freeing of one extent. We fix this by doing proper estimate of the amount of blocks that need to be revoked when removing blocks from the inode due to truncate or hole punching and otherwise reserve just a small amount of revoke credits for each transaction to accommodate freeing of xattrs block or so. Signed-off-by: Michael Jeanson --- instrumentation/events/lttng-module/ext4.h | 31 +++++++++++++++++++++- 1 file changed, 30 insertions(+), 1 deletion(-) diff --git a/instrumentation/events/lttng-module/ext4.h b/instrumentation/events/lttng-module/ext4.h index b2ca8a7..17809d2 100644 --- a/instrumentation/events/lttng-module/ext4.h +++ b/instrumentation/events/lttng-module/ext4.h @@ -1255,7 +1255,36 @@ LTTNG_TRACEPOINT_EVENT(ext4_load_inode, ) ) -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,11,0)) +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(5,5,0)) + +LTTNG_TRACEPOINT_EVENT(ext4_journal_start, + TP_PROTO(struct super_block *sb, int blocks, int rsv_blocks, + int revoke_creds, unsigned long IP), + + TP_ARGS(sb, blocks, rsv_blocks, revoke_creds, IP), + + TP_FIELDS( + ctf_integer(dev_t, dev, sb->s_dev) + ctf_integer(unsigned long, ip, IP) + ctf_integer(int, blocks, blocks) + ctf_integer(int, rsv_blocks, rsv_blocks) + ctf_integer(int, revoke_creds, revoke_creds) + ) +) + +LTTNG_TRACEPOINT_EVENT(ext4_journal_start_reserved, + TP_PROTO(struct super_block *sb, int blocks, unsigned long IP), + + TP_ARGS(sb, blocks, IP), + + TP_FIELDS( + ctf_integer(dev_t, dev, sb->s_dev) + ctf_integer(unsigned long, ip, IP) + ctf_integer(int, blocks, blocks) + ) +) + +#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(3,11,0)) LTTNG_TRACEPOINT_EVENT(ext4_journal_start, TP_PROTO(struct super_block *sb, int blocks, int rsv_blocks, -- 2.17.1 From mjeanson at efficios.com Tue Dec 10 11:41:13 2019 From: mjeanson at efficios.com (Michael Jeanson) Date: Tue, 10 Dec 2019 11:41:13 -0500 Subject: [lttng-dev] [PATCH lttng-modules] fix: btrfs block group struct refactor (v5.5) In-Reply-To: <20191210164114.26954-1-mjeanson@efficios.com> References: <20191210164114.26954-1-mjeanson@efficios.com> Message-ID: <20191210164114.26954-4-mjeanson@efficios.com> See upstream commits: commit 32da5386d9a4fd5c1155cecf703df104d918954c Author: David Sterba Date: Tue Oct 29 19:20:18 2019 +0100 btrfs: rename btrfs_block_group_cache The type name is misleading, a single entry is named 'cache' while this normally means a collection of objects. Rename that everywhere. Also the identifier was quite long, making function prototypes harder to format. commit b3470b5dbe1300dea94191ae4b7d070be9a5cdc9 Author: David Sterba Date: Wed Oct 23 18:48:22 2019 +0200 btrfs: add dedicated members for start and length of a block group The on-disk format of block group item makes use of the key that stores the offset and length. This is further used in the code, although this makes thing harder to understand. The key is also packed so the offset/length is not properly aligned as u64. Add start (key.objectid) and length (key.offset) members to block group and remove the embedded key. When the item is searched or written, a local variable for key is used. commit bf38be65f3703d5ef3661c0a2802bc28e76b8f19 Author: David Sterba Date: Wed Oct 23 18:48:11 2019 +0200 btrfs: move block_group_item::used to block group For unknown reasons, the member 'used' in the block group struct is stored in the b-tree item and accessed everywhere using the special accessor helper. Let's unify it and make it a regular member and only update the item before writing it to the tree. The item is still being used for flags and chunk_objectid, there's some duplication until the item is removed in following patches. Signed-off-by: Michael Jeanson --- instrumentation/events/lttng-module/btrfs.h | 125 +++++++++++++++++++- 1 file changed, 121 insertions(+), 4 deletions(-) diff --git a/instrumentation/events/lttng-module/btrfs.h b/instrumentation/events/lttng-module/btrfs.h index 59b668c..b4f2fe7 100644 --- a/instrumentation/events/lttng-module/btrfs.h +++ b/instrumentation/events/lttng-module/btrfs.h @@ -20,8 +20,12 @@ struct btrfs_delayed_ref_node; struct btrfs_delayed_tree_ref; struct btrfs_delayed_data_ref; struct btrfs_delayed_ref_head; -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,3,0)) +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(5,5,0)) +struct btrfs_block_group; +#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(3,3,0)) struct btrfs_block_group_cache; +#endif +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,3,0)) struct btrfs_free_cluster; #endif struct map_lookup; @@ -679,7 +683,25 @@ LTTNG_TRACEPOINT_EVENT(btrfs_sync_fs, ) #endif -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0) || \ +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(5,5,0)) +LTTNG_TRACEPOINT_EVENT(btrfs_add_block_group, + + TP_PROTO(const struct btrfs_fs_info *fs_info, + const struct btrfs_block_group *block_group, int create), + + TP_ARGS(fs_info, block_group, create), + + TP_FIELDS( + ctf_array(u8, fsid, lttng_fs_info_fsid, BTRFS_UUID_SIZE) + ctf_integer(u64, offset, block_group->start) + ctf_integer(u64, size, block_group->length) + ctf_integer(u64, flags, block_group->flags) + ctf_integer(u64, bytes_used, block_group->used) + ctf_integer(u64, bytes_super, block_group->bytes_super) + ctf_integer(int, create, create) + ) +) +#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0) || \ LTTNG_SLE_KERNEL_RANGE(4,4,73,5,0,0, 4,4,73,6,0,0) || \ LTTNG_SLE_KERNEL_RANGE(4,4,82,6,0,0, 4,4,82,7,0,0) || \ LTTNG_SLE_KERNEL_RANGE(4,4,92,6,0,0, 4,4,92,7,0,0) || \ @@ -1812,7 +1834,57 @@ LTTNG_TRACEPOINT_EVENT_INSTANCE(btrfs__reserved_extent, btrfs_reserved_extent_f #endif /* #else #if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,10,0)) */ -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,18,0)) +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(5,5,0)) +LTTNG_TRACEPOINT_EVENT_MAP(find_free_extent, + + btrfs_find_free_extent, + + TP_PROTO(const struct btrfs_fs_info *fs_info, u64 num_bytes, u64 empty_size, + u64 data), + + TP_ARGS(fs_info, num_bytes, empty_size, data), + + TP_FIELDS( + ctf_array(u8, fsid, lttng_fs_info_fsid, BTRFS_UUID_SIZE) + ctf_integer(u64, num_bytes, num_bytes) + ctf_integer(u64, empty_size, empty_size) + ctf_integer(u64, data, data) + ) +) + +LTTNG_TRACEPOINT_EVENT_CLASS(btrfs__reserve_extent, + + TP_PROTO(const struct btrfs_block_group *block_group, u64 start, + u64 len), + + TP_ARGS(block_group, start, len), + + TP_FIELDS( + ctf_array(u8, fsid, block_group->lttng_fs_info_fsid, BTRFS_UUID_SIZE) + ctf_integer(u64, bg_objectid, block_group->start) + ctf_integer(u64, flags, block_group->flags) + ctf_integer(u64, start, start) + ctf_integer(u64, len, len) + ) +) + +LTTNG_TRACEPOINT_EVENT_INSTANCE(btrfs__reserve_extent, btrfs_reserve_extent, + + TP_PROTO(const struct btrfs_block_group *block_group, u64 start, + u64 len), + + TP_ARGS(block_group, start, len) +) + +LTTNG_TRACEPOINT_EVENT_INSTANCE(btrfs__reserve_extent, btrfs_reserve_extent_cluster, + + TP_PROTO(const struct btrfs_block_group *block_group, u64 start, + u64 len), + + TP_ARGS(block_group, start, len) +) + +#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(4,18,0)) LTTNG_TRACEPOINT_EVENT_MAP(find_free_extent, btrfs_find_free_extent, @@ -2080,7 +2152,52 @@ LTTNG_TRACEPOINT_EVENT_INSTANCE(btrfs__reserve_extent, btrfs_reserve_extent_clus #endif /* #else #if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,10,0)) */ -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0) || \ +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(5,5,0)) +LTTNG_TRACEPOINT_EVENT(btrfs_find_cluster, + + TP_PROTO(const struct btrfs_block_group *block_group, u64 start, + u64 bytes, u64 empty_size, u64 min_bytes), + + TP_ARGS(block_group, start, bytes, empty_size, min_bytes), + + TP_FIELDS( + ctf_integer(u64, bg_objectid, block_group->start) + ctf_integer(u64, flags, block_group->flags) + ctf_integer(u64, start, start) + ctf_integer(u64, bytes, bytes) + ctf_integer(u64, empty_size, empty_size) + ctf_integer(u64, min_bytes, min_bytes) + ) +) + +LTTNG_TRACEPOINT_EVENT(btrfs_failed_cluster_setup, + + TP_PROTO(const struct btrfs_block_group *block_group), + + TP_ARGS(block_group), + + TP_FIELDS( + ctf_integer(u64, bg_objectid, block_group->start) + ) +) + +LTTNG_TRACEPOINT_EVENT(btrfs_setup_cluster, + + TP_PROTO(const struct btrfs_block_group *block_group, + const struct btrfs_free_cluster *cluster, u64 size, int bitmap), + + TP_ARGS(block_group, cluster, size, bitmap), + + TP_FIELDS( + ctf_integer(u64, bg_objectid, block_group->start) + ctf_integer(u64, flags, block_group->flags) + ctf_integer(u64, start, cluster->window_start) + ctf_integer(u64, max_size, cluster->max_size) + ctf_integer(u64, size, size) + ctf_integer(int, bitmap, bitmap) + ) +) +#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0) || \ LTTNG_SLE_KERNEL_RANGE(4,4,73,5,0,0, 4,4,73,6,0,0) || \ LTTNG_SLE_KERNEL_RANGE(4,4,82,6,0,0, 4,4,82,7,0,0) || \ LTTNG_SLE_KERNEL_RANGE(4,4,92,6,0,0, 4,4,92,7,0,0) || \ -- 2.17.1 From mathieu.desnoyers at efficios.com Tue Dec 10 12:19:32 2019 From: mathieu.desnoyers at efficios.com (Mathieu Desnoyers) Date: Tue, 10 Dec 2019 12:19:32 -0500 (EST) Subject: [lttng-dev] [PATCH lttng-modules] Update .gitignore from upstream In-Reply-To: <20191210164114.26954-1-mjeanson@efficios.com> References: <20191210164114.26954-1-mjeanson@efficios.com> Message-ID: <1344633017.1658.1575998372268.JavaMail.zimbra@efficios.com> All merged into master, stable-2.11, stable-2.10. Note that for stable-2.10, I had to pick up 2 extra commits for btrfs so the "constify" patch would apply cleanly: f059ce66 fix: ext4: Reserve revoke credits for freed blocks (v5.5) 57ff707e fix: btrfs: tracepoints: constify all pointers (v5.5) 065436fd Fix: btrfs: use fs_info for btrfs_handle_em_exist tracepoint 619cabe7 Add btrfs tracepoint for em's EEXIST case ef77ec63 fix: btrfs block group struct refactor (v5.5) b06bd5b7 fix: y2038: itimer: change implementation to timespec64 (v5.5) Thanks, Mathieu ----- On Dec 10, 2019, at 11:41 AM, Michael Jeanson mjeanson at efficios.com wrote: > Signed-off-by: Michael Jeanson > --- > .gitignore | 110 +++++++++++++++++++++++++++++++++++++++++++---------- > 1 file changed, 89 insertions(+), 21 deletions(-) > > diff --git a/.gitignore b/.gitignore > index 38e1684..4af69a2 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -7,30 +7,45 @@ > # command after changing this file, to see if there are > # any tracked files which get ignored after the change. > # > -# Normal rules > +# Normal rules (sorted alphabetically) > # > .* > +*.a > +*.asn1.[ch] > +*.bin > +*.bz2 > +*.c.[012]*.* > +*.dt.yaml > +*.dtb > +*.dtb.S > +*.dwo > +*.elf > +*.gcno > +*.gz > +*.i > +*.ko > +*.lex.c > +*.ll > +*.lst > +*.lz4 > +*.lzma > +*.lzo > +*.mod > +*.mod.c > *.o > *.o.* > -*.a > +*.patch > *.s > -*.ko > *.so > *.so.dbg > -*.mod.c > -*.i > -*.lst > +*.su > *.symtypes > -*.order > +*.tab.[ch] > +*.tar > +*.xz > +Module.symvers > modules.builtin > -*.elf > -*.bin > -*.gz > -*.bz2 > -*.lzma > -*.lzo > -*.gcno > -cscope.* > +modules.order > > # > # Top-level generic files > @@ -39,25 +54,51 @@ cscope.* > /TAGS > /linux > /vmlinux > +/vmlinux.32 > +/vmlinux-gdb.py > /vmlinuz > /System.map > /Module.markers > +/modules.builtin.modinfo > +/modules.nsdeps > > -# ignore across tree > -Module.symvers > +# > +# RPM spec file (make rpm-pkg) > +# > +/*.spec > + > +# > +# Debian directory (make deb-pkg) > +# > +/debian/ > + > +# > +# Snap directory (make snap-pkg) > +# > +/snap/ > + > +# > +# tar directory (make tar*-pkg) > +# > +/tar-install/ > > # > -# git files that we don't want to ignore even it they are dot-files > +# We don't want to ignore the following even if they are dot-files > # > +!.clang-format > +!.cocciconfig > +!.get_maintainer.ignore > +!.gitattributes > !.gitignore > !.mailmap > > # > # Generated include files > # > -include/config > -include/linux/version.h > -include/generated > +/include/config/ > +/include/generated/ > +/include/ksym/ > +/arch/*/include/generated/ > > # stgit generated dirs > patches-* > @@ -76,8 +117,35 @@ GRTAGS > GSYMS > GTAGS > > +# id-utils files > +ID > + > *.orig > *~ > \#*# > > +# > +# Leavings from module signing > +# > +extra_certificates > +signing_key.pem > +signing_key.priv > +signing_key.x509 > +x509.genkey > + > +# Kconfig presets > +/all.config > +/alldef.config > +/allmod.config > +/allno.config > +/allrandom.config > +/allyes.config > + > +# Kdevelop4 > +*.kdev4 > + > +# Clang's compilation database file > +/compile_commands.json > + > +# lttng-modules specific > /extra_version > -- > 2.17.1 -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com From mjeanson at efficios.com Wed Dec 11 15:29:17 2019 From: mjeanson at efficios.com (Michael Jeanson) Date: Wed, 11 Dec 2019 15:29:17 -0500 Subject: [lttng-dev] [PATCH lttng-modules stable-2.10] fix: missing 'lttng_fs_info_fsid' wrapper in btrfs backport Message-ID: <20191211202917.28820-1-mjeanson@efficios.com> The following backported patch was missing the use of the 'lttng_fs_info_fsid' wrapper to enable compatibility with upstream stable kernels. commit 065436fd07d58a9a17427ad386ffcc8d29e25a9d Author: Michael Jeanson Date: Mon Jun 18 14:53:18 2018 -0400 Fix: btrfs: use fs_info for btrfs_handle_em_exist tracepoint See upstream commit: commit f46b24c9457143a367c6707eac82d546e2bcf280 Author: David Sterba Date: Tue Apr 3 21:45:57 2018 +0200 btrfs: use fs_info for btrfs_handle_em_exist tracepoint We really want to know to which filesystem the extent map events belong, but as it cannot be reached from the extent_map pointers, we need to pass it down the callchain. Signed-off-by: Michael Jeanson Signed-off-by: Mathieu Desnoyers Signed-off-by: Michael Jeanson --- instrumentation/events/lttng-module/btrfs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/instrumentation/events/lttng-module/btrfs.h b/instrumentation/events/lttng-module/btrfs.h index fbedd6c..c8c494a 100644 --- a/instrumentation/events/lttng-module/btrfs.h +++ b/instrumentation/events/lttng-module/btrfs.h @@ -318,7 +318,7 @@ LTTNG_TRACEPOINT_EVENT(btrfs_handle_em_exist, TP_ARGS(fs_info, existing, map, start, len), TP_FIELDS( - ctf_array(u8, fsid, fs_info->fsid, BTRFS_UUID_SIZE) + ctf_array(u8, fsid, lttng_fs_info_fsid, BTRFS_UUID_SIZE) ctf_integer(u64, e_start, existing->start) ctf_integer(u64, e_len, existing->len) ctf_integer(u64, map_start, map->start) -- 2.17.1 From mathieu.desnoyers at efficios.com Wed Dec 11 16:00:13 2019 From: mathieu.desnoyers at efficios.com (Mathieu Desnoyers) Date: Wed, 11 Dec 2019 16:00:13 -0500 (EST) Subject: [lttng-dev] [PATCH lttng-modules stable-2.10] fix: missing 'lttng_fs_info_fsid' wrapper in btrfs backport In-Reply-To: <20191211202917.28820-1-mjeanson@efficios.com> References: <20191211202917.28820-1-mjeanson@efficios.com> Message-ID: <1339411647.2911.1576098013169.JavaMail.zimbra@efficios.com> Merged, thanks! Mathieu ----- On Dec 11, 2019, at 3:29 PM, Michael Jeanson mjeanson at efficios.com wrote: > The following backported patch was missing the use of the > 'lttng_fs_info_fsid' wrapper to enable compatibility with upstream > stable kernels. > > commit 065436fd07d58a9a17427ad386ffcc8d29e25a9d > Author: Michael Jeanson > Date: Mon Jun 18 14:53:18 2018 -0400 > > Fix: btrfs: use fs_info for btrfs_handle_em_exist tracepoint > > See upstream commit: > > commit f46b24c9457143a367c6707eac82d546e2bcf280 > Author: David Sterba > Date: Tue Apr 3 21:45:57 2018 +0200 > > btrfs: use fs_info for btrfs_handle_em_exist tracepoint > > We really want to know to which filesystem the extent map events belong, > but as it cannot be reached from the extent_map pointers, we need to > pass it down the callchain. > > Signed-off-by: Michael Jeanson > Signed-off-by: Mathieu Desnoyers > > Signed-off-by: Michael Jeanson > --- > instrumentation/events/lttng-module/btrfs.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/instrumentation/events/lttng-module/btrfs.h > b/instrumentation/events/lttng-module/btrfs.h > index fbedd6c..c8c494a 100644 > --- a/instrumentation/events/lttng-module/btrfs.h > +++ b/instrumentation/events/lttng-module/btrfs.h > @@ -318,7 +318,7 @@ LTTNG_TRACEPOINT_EVENT(btrfs_handle_em_exist, > TP_ARGS(fs_info, existing, map, start, len), > > TP_FIELDS( > - ctf_array(u8, fsid, fs_info->fsid, BTRFS_UUID_SIZE) > + ctf_array(u8, fsid, lttng_fs_info_fsid, BTRFS_UUID_SIZE) > ctf_integer(u64, e_start, existing->start) > ctf_integer(u64, e_len, existing->len) > ctf_integer(u64, map_start, map->start) > -- > 2.17.1 -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com From mathieu.desnoyers at efficios.com Thu Dec 12 10:46:20 2019 From: mathieu.desnoyers at efficios.com (Mathieu Desnoyers) Date: Thu, 12 Dec 2019 10:46:20 -0500 (EST) Subject: [lttng-dev] [PATCH] Fix: SUNRPC: Fix oops when trace sunrpc_task events in nfs client In-Reply-To: <20191205073532.1278-1-quanyang.wang@windriver.com> References: <20191205073532.1278-1-quanyang.wang@windriver.com> Message-ID: <996784759.3725.1576165580909.JavaMail.zimbra@efficios.com> Merged into lttng-modules master, 2.11, 2.10 branches, thanks! I added the following commits on top, taking care of another OOPS that was missed by this patch, and adapting the type of the field to a signed integer: commit b6903d57e4c3234ec5b1c7f72e232023cdee0fab Author: Mathieu Desnoyers Date: Thu Dec 12 10:39:38 2019 -0500 sunrpc: introduce lttng_get_clid helper Introduce the lttng_get_clid helper to always check for NULL pointer when getting the client id. While not always strictly needed depending on the tracepoint callsite, prefer robustness of instrumentation and always check for NULL rather than play whack-a-mole. Signed-off-by: Mathieu Desnoyers commit 70389e422dd3146161089d454f525367c9046ecd Author: Mathieu Desnoyers Date: Thu Dec 12 10:29:37 2019 -0500 Fix: sunrpc: use signed integer for client id Within include/linux/sunrpc/clnt.h:struct rpc_cltn, the cl_clid field is an unsigned integer, which is the type expected by the tracepoint signature. However, looking into net/sunrpc/clnt.c:rpc_alloc_clid(), its allocation considers negative signed integer as errors. Therefore, in order to properly show "-1" in the trace output (rather than MAX_INT) when called with a NULL task->tk_client, move to a signed integer as backing type for the client_id field. Signed-off-by: Mathieu Desnoyers commit 032a74d83b263c4faead8e4c25d497fb8ea07b6e Author: Mathieu Desnoyers Date: Thu Dec 12 10:29:02 2019 -0500 Fix: sunrpc: null rpc_clnt dereference in rpc_task_queued tracepoint Based on upstream Linux commit: commit 0be283f676a1e7b208db0c992283197ef8b52158 Author: Benjamin Coddington Date: Tue Jan 23 09:32:35 2018 -0500 SUNRPC: Fix null rpc_clnt dereference in rpc_task_queued tracepoint Backchannel tasks will not have a reference to the rpc_clnt. Return -1 for cl_clid in that case. Signed-off-by: Benjamin Coddington Signed-off-by: Trond Myklebust Signed-off-by: Mathieu Desnoyers ----- On Dec 5, 2019, at 2:35 AM, quanyang wang quanyang.wang at windriver.com wrote: > From: Quanyang Wang > > See upstream commit : > > commit 2ca310fc4160ed0420da65534a21ae77b24326a8 > Author: Ditang Chen > Date: Fri, 7 Mar 2014 13:27:57 +0800 > Subject: SUNRPC: Fix oops when trace sunrpc_task events in nfs client > > When tracking sunrpc_task events in nfs client, the clnt pointer may be NULL. > > [ 139.269266] BUG: unable to handle kernel NULL pointer dereference at > 0000000000000004 > [ 139.269915] IP: [] > ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc] > [ 139.269915] PGD 1d293067 PUD 1d294067 PMD 0 > [ 139.269915] Oops: 0000 [#1] SMP > [ 139.269915] Modules linked in: nfsv4 dns_resolver nfs lockd sunrpc fscache sg > ppdev e1000 > serio_raw pcspkr parport_pc parport i2c_piix4 i2c_core microcode xfs libcrc32c > sd_mod sr_mod > cdrom ata_generic crc_t10dif crct10dif_common pata_acpi ahci libahci ata_piix > libata dm_mirror > dm_region_hash dm_log dm_mod > [ 139.269915] CPU: 0 PID: 59 Comm: kworker/0:2 Not tainted 3.10.0-84.el7.x86_64 > #1 > [ 139.269915] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS > VirtualBox 12/01/2006 > [ 139.269915] Workqueue: rpciod rpc_async_schedule [sunrpc] > [ 139.269915] task: ffff88001b598000 ti: ffff88001b632000 task.ti: > ffff88001b632000 > [ 139.269915] RIP: 0010:[] [] > ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc] > [ 139.269915] RSP: 0018:ffff88001b633d70 EFLAGS: 00010206 > [ 139.269915] RAX: ffff88001dfc5338 RBX: ffff88001cc37a00 RCX: ffff88001dfc5334 > [ 139.269915] RDX: ffff88001dfc5338 RSI: 0000000000000000 RDI: ffff88001dfc533c > [ 139.269915] RBP: ffff88001b633db0 R08: 000000000000002c R09: 000000000000000a > [ 139.269915] R10: 0000000000062180 R11: 00000020759fb9dc R12: ffffffffa0292c20 > [ 139.269915] R13: ffff88001dfc5334 R14: 0000000000000000 R15: 0000000000000000 > [ 139.269915] FS: 0000000000000000(0000) GS:ffff88001fc00000(0000) > knlGS:0000000000000000 > [ 139.269915] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 139.269915] CR2: 0000000000000004 CR3: 000000001d290000 CR4: 00000000000006f0 > [ 139.269915] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 139.269915] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [ 139.269915] Stack: > [ 139.269915] 000000001b633d98 0000000000000246 ffff88001df1dc00 > ffff88001cc37a00 > [ 139.269915] ffff88001bc35e60 0000000000000000 ffff88001ffa0a48 > ffff88001bc35ee0 > [ 139.269915] ffff88001b633e08 ffffffffa02704b5 0000000000010000 > ffff88001cc37a70 > [ 139.269915] Call Trace: > [ 139.269915] [] __rpc_execute+0x1d5/0x400 [sunrpc] > [ 139.269915] [] rpc_async_schedule+0x26/0x30 [sunrpc] > [ 139.269915] [] process_one_work+0x17b/0x460 > [ 139.269915] [] worker_thread+0x11b/0x400 > [ 139.269915] [] ? rescuer_thread+0x3e0/0x3e0 > [ 139.269915] [] kthread+0xc0/0xd0 > [ 139.269915] [] ? kthread_create_on_node+0x110/0x110 > [ 139.269915] [] ret_from_fork+0x7c/0xb0 > [ 139.269915] [] ? kthread_create_on_node+0x110/0x110 > [ 139.269915] Code: 4c 8b 45 c8 48 8d 7d d0 89 4d c4 41 89 c9 b9 28 00 00 00 e8 > 9d b4 e9 > e0 48 85 c0 49 89 c5 74 a2 48 89 c7 e8 9d 3f e9 e0 48 89 c2 <41> 8b 46 04 48 8b > 7d d0 4c > 89 e9 4c 89 e6 89 42 0c 0f b7 83 d4 > [ 139.269915] RIP [] > ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc] > [ 139.269915] RSP > [ 139.269915] CR2: 0000000000000004 > [ 140.946406] ---[ end trace ba486328b98d7622 ]--- > > Signed-off-by: Quanyang Wang > --- > instrumentation/events/lttng-module/rpc.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/instrumentation/events/lttng-module/rpc.h > b/instrumentation/events/lttng-module/rpc.h > index 3798e8e..fb13106 100644 > --- a/instrumentation/events/lttng-module/rpc.h > +++ b/instrumentation/events/lttng-module/rpc.h > @@ -139,7 +139,7 @@ LTTNG_TRACEPOINT_EVENT_CLASS(rpc_task_running, > > TP_FIELDS( > ctf_integer(unsigned int, task_id, task->tk_pid) > - ctf_integer(unsigned int, client_id, task->tk_client->cl_clid) > + ctf_integer(unsigned int, client_id, task->tk_client ? > task->tk_client->cl_clid : -1) > ctf_integer_hex(const void *, action, action) > ctf_integer(unsigned long, runstate, task->tk_runstate) > ctf_integer(int, status, task->tk_status) > @@ -208,7 +208,7 @@ LTTNG_TRACEPOINT_EVENT_CLASS(rpc_task_running, > > TP_FIELDS( > ctf_integer(unsigned int, task_id, task->tk_pid) > - ctf_integer(unsigned int, client_id, task->tk_client->cl_clid) > + ctf_integer(unsigned int, client_id, task->tk_client ? > task->tk_client->cl_clid : -1) > ctf_integer_hex(const void *, action, action) > ctf_integer(unsigned long, runstate, task->tk_runstate) > ctf_integer(int, status, task->tk_status) > -- > 2.17.1 -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com From jeremie.galarneau at efficios.com Thu Dec 12 20:03:30 2019 From: jeremie.galarneau at efficios.com (=?UTF-8?Q?J=C3=A9r=C3=A9mie_Galarneau?=) Date: Thu, 12 Dec 2019 20:03:30 -0500 Subject: [lttng-dev] [PATCH babeltrace-1.5 6/6] Fix: lttng-live format: do not error out on empty streams hang up In-Reply-To: <20191205065809.16728-7-mathieu.desnoyers@efficios.com> References: <20191205065809.16728-1-mathieu.desnoyers@efficios.com> <20191205065809.16728-7-mathieu.desnoyers@efficios.com> Message-ID: All patches of this series were merged in stable-1.5. Thanks! J?r?mie On Thu, 5 Dec 2019 at 01:58, Mathieu Desnoyers wrote: > > Attaching to a stream hung up before providing any trace packet > causes ctf_open_mmap_stream_read() to return an error. > > This kind of scenario can happen with the upcoming "lttng clear" > feature. > > Signed-off-by: Mathieu Desnoyers > --- > formats/ctf/ctf.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/formats/ctf/ctf.c b/formats/ctf/ctf.c > index 980ebc9a..1ba9017f 100644 > --- a/formats/ctf/ctf.c > +++ b/formats/ctf/ctf.c > @@ -2571,8 +2571,13 @@ int ctf_open_mmap_stream_read(struct ctf_trace *td, > } > > ret = prepare_mmap_stream_definition(td, file_stream, packet_seek); > - if (ret) > + if (ret) { > + /* We need to check for EOF here for empty files. */ > + if (unlikely(file_stream->pos.offset == EOF)) { > + ret = 0; > + } > goto error_index; > + } > > /* > * For now, only a single clock per trace is supported. > -- > 2.17.1 > -- J?r?mie Galarneau EfficiOS Inc. http://www.efficios.com From ryx at gwmail.gwu.edu Sat Dec 14 01:31:31 2019 From: ryx at gwmail.gwu.edu (Yuxin Ren) Date: Sat, 14 Dec 2019 01:31:31 -0500 Subject: [lttng-dev] RCU consistency guarantees In-Reply-To: <20191207224232.GR2889@paulmck-ThinkPad-P72> References: <194534011.751.1575629349181.JavaMail.zimbra@efficios.com> <512711764.1078.1575647945136.JavaMail.zimbra@efficios.com> <20191206163052.GG2889@paulmck-ThinkPad-P72> <20191207063730.GN2889@paulmck-ThinkPad-P72> <20191207224232.GR2889@paulmck-ThinkPad-P72> Message-ID: Hi Paul On Sat, Dec 7, 2019 at 5:42 PM Paul E. McKenney wrote: > On Sat, Dec 07, 2019 at 03:04:42PM -0500, Yuxin Ren wrote: > > Thanks a lot for your help. I have some questions below. > > > > On Sat, Dec 7, 2019 at 1:37 AM Paul E. McKenney > wrote: > > > > > On Fri, Dec 06, 2019 at 07:00:13PM -0500, Yuxin Ren wrote: > > > > Thanks so much for your great help. > > > > I definitely will look at those resources and papers! > > > > > > > > One more thing that I am confused > > > > As I mentioned earlier, someone said One key distinction is that both > > > MVCC > > > > and RLU provide much stronger consistency guarantees to readers than > does > > > > RCU ...) (https://lwn.net/Articles/777036/). > > > > > > That someone was in fact me. ;-) > > > > > > > I am not sure if the above statement is correct or not. But in > general, > > > > How can we compare RCU consistency guarantees to other techniques > (such > > > as > > > > RLU)? > > > > How to reason about which one has stronger or weaker guarantees? > > > > > > I suggest starting from the use case. For concreteness, let's assume > > > that we are using a hash table. At one extreme, imagine a use case in > > > which each event makes exactly one hash-table operation. No > information > > > is carried from one event to the next. (This might well be the case > > > for simple web server.) Such a use case cannot tell the difference > > > between RCU on the one hand and MVCC/RLU on the other. > > > > > > At the other extreme, suppose that each event either accesses or > updates > > > multiple entries in the hash table. In this case, MVCC/RLU will rule > > > out outcomes that RCU would permit. For example, suppose we had four > > > events accessing two different elements in different buckets of the > > > hash table: > > > > > > E1: Adds 32 to the hash table. > > > E2: Adds 1729 to the hash table. > > > E3: Within a read-side critical section, looks up 32 then 1729. > > > E4: Within a read-side critical section, looks up 1729 then 32. > > > > > > Given either MVCC or RLU, it will not be possible for E3 to find 32 but > > > not 1729 and at the same time for E4 to find 1729 but not 32. Given > RCU, > > > this outcome is possible. > > > > > When you say "Within a read-side section", do you mean within a single > same > > read section? such as > > > > > read_lock() > > > lookup(32) > > > lookup(1729) > > > read_unlock() > > > > > > How about putting two lookups into two read-side sections? Do we still > have > > the problem, then? > > > > > read_lock() > > > lookup(32) > > > read_unlock() > > > read_lock() > > > lookup(1729) > > > read_unlock() > > Without in any way agreeing with your characterization of this as a > problem, because rcu_read_lock() and rcu_read_unlock() provide > absolutely no ordering guarantees in the absence of a grace period, > any non-grace-period-related reordering that can happen with a single > RCU read-side critical section can also happen when that critical > section is split in two as you have done above. > > > Could you kindly give me more clues why RCU can see such reorder, while > RLU > > can prevent it? > > Here are minimal C-language implementations for RCU that can (and are) > actually used: > Great. We use the same thing in our real-time work [1] > #define rcu_read_lock() > #define rcu_read_unlock() > > Please compare these to the read-side markers presented in the RLU paper, > and then tell me your thoughts on the answer to your question. ;-) > I submit my homework here, but I do not think I did it well. 1. I believe in the default URCU implementation, it has memory barrier inside the read_lock / read_unlock. 2. From the RLU paper, it shows the code for read-side operation. RLU_READER_LOCK(ctx) ctx.is-writer?false ctx.run-cnt?ctx.run-cnt+1. memory fence ctx.local-clock?global-clock RLU_READER_UNLOCK(ctx) ctx.run-cnt?ctx.run-cnt+1 if (ctx.is-writer) RLU_COMMIT_WRITE_LOG(ctx) We can ignore the writer check, as in our case, the reader never do update. My understanding is that read-side operations are only used to facilitate the quiescence detection. the run cnt is used to decide if a thread is active (if it is currently inside a read-side section). the local clock is used to check if the active thread goes into the read-side section very late, so it does not prevent reclaiming memory unlinked before it enters the read section. However i see no difference between RLU and RCU read-side operation regarding consistency guarantee. Could you kindly teach me more? BTW, the RLU read-side ops are similar, but not efficient, comparing to our Parsec work [1, 2] [1] Yuxin Ren, G. Liu, G. Parmer, B. Brandenburg, Scalable Memory Reclamation for Multi-Core, Real-Time Systems, in Proceedings of the 24th IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS), 2018 [2] Q. Wang, T. Stamler, and G. Parmer, Parallel Sections: Scaling System-Level Data-Structures, in Proceedings of European Conference on Computer Systems (EuroSys), 2016 Thanks, Best, Yuxin > > This is because MVCC and RLU provide readers a consistent view of > > > the updates, and RCU does not. Of course, it is often the case that a > > > consistent view is not needed, in which case the MVCC and RLU > guarantees > > > are incurring read-side overhead for no reason. But if the use case > > > requires consistent readers, RCU is not an option. > > > > > > The reason a consistent view is not always needed is that > speed-of-light > > > delays make it impossible to provide a consistent view of the outside > > > world. In the common case where the use case interacts with the > > > outside world, the algorithms absolutely must be designed to tolerate > > > inconsistency, which opens the door to things like RCU. > > > > I am confused here. I think speed-of-light delays happen everywhere, not > > only bound to RCU, but also any other synchronization approach (such > RLU). > > If so, how do others (RLU) provide consistent views? > > You just stated the answer. Now it is only necessary for you to invest > the time, effort, and thought to fully understand it. To help with this, > the following paragraph provides another hint: > > Yes, you are quite right, speed-of-light delays between the > outside world and the computer affect RLU just as surely as they > do RCU. This means that the additional consistency guarantees > provided by RLU must necessarily be limited to the confines of the > computer system in question. Taking this one step further, there > are also speed-of-light delays within the computer. Therefore, > in the general case, RLU can provide its consistency guarantees, > even within the confines of the computer system, only at the > expense of incurring delays. Because RCU does not provide RLU's > consistency guarantees, it need not incur RLU's delays. > > This is not a new line of reasoning, see for example: > > @article{Herlihy:1996:LCN:1063369.1063372 > ,author = {Herlihy, Maurice and Shavit, Nir and Waarts, Orli} > ,title = {Linearizable counting networks} > ,journal = {Distrib. Comput.} > ,volume = {9} > ,issue = {4} > ,month = {February} > ,year = {1996} > ,issn = {0178-2770} > ,pages = {193--203} > ,numpages = {11} > ,url = {http://portal.acm.org/citation.cfm?id=1063369.1063372} > ,doi = {10.1007/s004460050019} > ,acmid = {1063372} > ,publisher = {Springer-Verlag} > ,address = {London, UK} > ,keywords = {concurrency, contention, counting networks, data structures, > linearizability} > } > > Thanx, Paul > > > Thanks for your education. > > Yuxin > > > > > > > > Thanx, Paul > > > > > > > Thanks > > > > Yuxin > > > > > > > > On Fri, Dec 6, 2019 at 11:30 AM Paul E. McKenney > > > > wrote: > > > > > > > > > On Fri, Dec 06, 2019 at 10:59:05AM -0500, Mathieu Desnoyers wrote: > > > > > > ----- On Dec 6, 2019, at 3:51 PM, Yuxin Ren > > > wrote: > > > > > > > > > > > > > On Fri, Dec 6, 2019 at 5:49 AM Mathieu Desnoyers < [ > > > > > > > mailto:mathieu.desnoyers at efficios.com | > > > mathieu.desnoyers at efficios.com > > > > > ] > > > > > > > > wrote: > > > > > > > > > > > > >> ----- On Dec 5, 2019, at 8:17 PM, Yuxin Ren < [ mailto: > > > > > ryx at gwmail.gwu.edu | > > > > > > >> ryx at gwmail.gwu.edu ] > wrote: > > > > > > > > > > > > >>> Hi, > > > > > > >>> I am a student, and learning RCU now, but still know very > little > > > > > about it. > > > > > > >>> Are there any documents/papers/materials which (in)formally > > > define > > > > > and explain > > > > > > >>> RCU consistency guarantees? > > > > > > > > > > > > >> You may want to have a look at > > > > > > > > > > > > >> User-Level Implementations of Read-Copy Update > > > > > > >> Article in IEEE Transactions on Parallel and Distributed > Systems > > > > > 23(2):375 - 382 > > > > > > >> ? March 2012 > > > > > > > > > > > > > Thanks for your info. > > > > > > > However, I do not think URCU talks about any consistency model > > > > > formally. > > > > > > > > > > > > > From previous communication with Paul, he said RCU is not > designed > > > for > > > > > > > linearizability, and it is totally acceptable that RCU is not > > > > > linearizable. > > > > > > > However, I am curious how to accurately/formally Characterize > RCU > > > > > consistency > > > > > > > model/guarantees > > > > > > > > > > > > Adding Paul E. McKenney in CC. > > > > > > > > > > > > I am referring to the section "Overview of RCU semantics" in the > > > paper. > > > > > Not sure it has the level of > > > > > > formality you are looking for though. Paul, do you have pointers > to > > > > > additional material ? > > > > > > > > > > Indeed I do! The Linux kernel memory model (LKMM) includes RCU. > It is > > > > > in tools/memory-model in recent kernel source trees, which includes > > > > > documentation. This is an executable model, which means that you > > > > > can create litmus tests and have the model formally and > automatically > > > > > evaluate them. > > > > > > > > > > There are also a number of publications covering LKMM: > > > > > > > > > > o A formal kernel memory-ordering model > > > > > https://lwn.net/Articles/718628/ > > > > > https://lwn.net/Articles/720550/ > > > > > > > > > > These cover the release stores and dependency ordering that > > > > > provide RCU's publish-subscribe guarantees. > > > > > > > > > > Backup material here: > > > > > > > > > > > > > > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/ > > > > > > > > > > With these two likely being of particular interest: > > > > > > > > > > > > > > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/RCUguarantees.html > > > > > > > > > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/srcu.html > > > > > > > > > > o Frightening Small Children and Disconcerting Grown-ups: > > > > > Concurrency in the Linux Kernel > > > > > https://dl.acm.org/citation.cfm?id=3177156 > > > > > > http://www0.cs.ucl.ac.uk/staff/j.alglave/papers/asplos18.pdf > > > > > > > > > > Backup material: > > > > > > > > > > http://diy.inria.fr/linux/ > > > > > > > > > > o Who's afraid of a big bad optimizing compiler? > > > > > https://lwn.net/Articles/793253/ > > > > > > > > > > o Calibrating your fear of big bad optimizing compilers > > > > > https://lwn.net/Articles/799218/ > > > > > > > > > > These last two justify use of normal C-language assignment > > > > > statements to initialize and access data referenced by > > > > > RCU-protected pointers. > > > > > > > > > > There is a large body of litmus tests (thousands of them) here: > > > > > > > > > > https://github.com/paulmckrcu/litmus > > > > > > > > > > Many of these litmus tests involve RCU, and these can be located by > > > > > search for files containing rcu_read_lock(), rcu_read_unlock(), > > > > > synchronize_rcu(), and so on. > > > > > > > > > > Or were you looking for something else? > > > > > > > > > > Thanx, Paul > > > > > > > > > > > Thanks, > > > > > > > > > > > > Mathieu > > > > > > > > > > > > >> as a starting point. > > > > > > > > > > > > >> Thanks, > > > > > > > > > > > > >> Mathieu > > > > > > > > > > > > >>> I know there are some consistency models in the database area > > > (such > > > > > as PRAM, > > > > > > >>> Read Uncommitted, etc) from [ https://jepsen.io/consistency > | > > > > > > >>> https://jepsen.io/consistency ] and [1]. > > > > > > >>> How does RCU related to those consistency models? > > > > > > > > > > > > >>> I also found some comments online (One key distinction is > that > > > both > > > > > MVCC and RLU > > > > > > >>> provide much stronger consistency guarantees to readers than > does > > > > > RCU ...) ( [ > > > > > > >>> https://lwn.net/Articles/777036/ | > > > https://lwn.net/Articles/777036/ > > > > > ] ). > > > > > > >>> I do not understand how we reason/dresibe/compare the > consistency > > > > > guarantees. ( > > > > > > >>> I even do not know what consistency guarantees provided by > RCU > > > > > formally) > > > > > > >>> Could someone explain this to me? > > > > > > > > > > > > >>> [1] Bailis, P., Davidson, A., Fekete, A., Ghodsi, A., > > > Hellerstein, > > > > > J. M., & > > > > > > >>> Stoica, I. (2013). Highly available transactions: Virtues and > > > > > limitations. > > > > > > >>> Proceedings of the VLDB Endowment, 7(3), 181-192. > > > > > > > > > > > > >>> Thanks > > > > > > >>> Yuxin > > > > > > > > > > > > >>> _______________________________________________ > > > > > > >>> lttng-dev mailing list > > > > > > >>> [ mailto:lttng-dev at lists.lttng.org | > lttng-dev at lists.lttng.org ] > > > > > > >>> [ https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > | > > > > > > >>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ] > > > > > > > > > > > > >> -- > > > > > > >> Mathieu Desnoyers > > > > > > >> EfficiOS Inc. > > > > > > >> [ http://www.efficios.com/ | http://www.efficios.com ] > > > > > > > > > > > > -- > > > > > > Mathieu Desnoyers > > > > > > EfficiOS Inc. > > > > > > http://www.efficios.com > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paulmck at kernel.org Sun Dec 15 15:30:19 2019 From: paulmck at kernel.org (Paul E. McKenney) Date: Sun, 15 Dec 2019 12:30:19 -0800 Subject: [lttng-dev] RCU consistency guarantees In-Reply-To: References: <194534011.751.1575629349181.JavaMail.zimbra@efficios.com> <512711764.1078.1575647945136.JavaMail.zimbra@efficios.com> <20191206163052.GG2889@paulmck-ThinkPad-P72> <20191207063730.GN2889@paulmck-ThinkPad-P72> <20191207224232.GR2889@paulmck-ThinkPad-P72> Message-ID: <20191215203019.GN2889@paulmck-ThinkPad-P72> On Sat, Dec 14, 2019 at 01:31:31AM -0500, Yuxin Ren wrote: > Hi Paul > > On Sat, Dec 7, 2019 at 5:42 PM Paul E. McKenney wrote: > > > On Sat, Dec 07, 2019 at 03:04:42PM -0500, Yuxin Ren wrote: > > > Thanks a lot for your help. I have some questions below. > > > > > > On Sat, Dec 7, 2019 at 1:37 AM Paul E. McKenney > > wrote: > > > > > > > On Fri, Dec 06, 2019 at 07:00:13PM -0500, Yuxin Ren wrote: > > > > > Thanks so much for your great help. > > > > > I definitely will look at those resources and papers! > > > > > > > > > > One more thing that I am confused > > > > > As I mentioned earlier, someone said One key distinction is that both > > > > MVCC > > > > > and RLU provide much stronger consistency guarantees to readers than > > does > > > > > RCU ...) (https://lwn.net/Articles/777036/). > > > > > > > > That someone was in fact me. ;-) > > > > > > > > > I am not sure if the above statement is correct or not. But in > > general, > > > > > How can we compare RCU consistency guarantees to other techniques > > (such > > > > as > > > > > RLU)? > > > > > How to reason about which one has stronger or weaker guarantees? > > > > > > > > I suggest starting from the use case. For concreteness, let's assume > > > > that we are using a hash table. At one extreme, imagine a use case in > > > > which each event makes exactly one hash-table operation. No > > information > > > > is carried from one event to the next. (This might well be the case > > > > for simple web server.) Such a use case cannot tell the difference > > > > between RCU on the one hand and MVCC/RLU on the other. > > > > > > > > At the other extreme, suppose that each event either accesses or > > updates > > > > multiple entries in the hash table. In this case, MVCC/RLU will rule > > > > out outcomes that RCU would permit. For example, suppose we had four > > > > events accessing two different elements in different buckets of the > > > > hash table: > > > > > > > > E1: Adds 32 to the hash table. > > > > E2: Adds 1729 to the hash table. > > > > E3: Within a read-side critical section, looks up 32 then 1729. > > > > E4: Within a read-side critical section, looks up 1729 then 32. > > > > > > > > Given either MVCC or RLU, it will not be possible for E3 to find 32 but > > > > not 1729 and at the same time for E4 to find 1729 but not 32. Given > > RCU, > > > > this outcome is possible. > > > > > > > When you say "Within a read-side section", do you mean within a single > > same > > > read section? such as > > > > > > > read_lock() > > > > lookup(32) > > > > lookup(1729) > > > > read_unlock() > > > > > > > > > How about putting two lookups into two read-side sections? Do we still > > have > > > the problem, then? > > > > > > > read_lock() > > > > lookup(32) > > > > read_unlock() > > > > read_lock() > > > > lookup(1729) > > > > read_unlock() > > > > Without in any way agreeing with your characterization of this as a > > problem, because rcu_read_lock() and rcu_read_unlock() provide > > absolutely no ordering guarantees in the absence of a grace period, > > any non-grace-period-related reordering that can happen with a single > > RCU read-side critical section can also happen when that critical > > section is split in two as you have done above. > > > > > Could you kindly give me more clues why RCU can see such reorder, while > > RLU > > > can prevent it? > > > > Here are minimal C-language implementations for RCU that can (and are) > > actually used: > > > Great. We use the same thing in our real-time work [1] It has been a popular choice for 40 years now. ;-) > > #define rcu_read_lock() > > #define rcu_read_unlock() > > > > Please compare these to the read-side markers presented in the RLU paper, > > and then tell me your thoughts on the answer to your question. ;-) > > > I submit my homework here, but I do not think I did it well. > 1. I believe in the default URCU implementation, it has memory barrier > inside the read_lock / read_unlock. It certainly was at one time. But you would of course need to check to see what any given worker actually used. > 2. From the RLU paper, it shows the code for read-side operation. > RLU_READER_LOCK(ctx) > ctx.is-writer?false > ctx.run-cnt?ctx.run-cnt+1. > memory fence > ctx.local-clock?global-clock > RLU_READER_UNLOCK(ctx) > ctx.run-cnt?ctx.run-cnt+1 > if (ctx.is-writer) > RLU_COMMIT_WRITE_LOG(ctx) > > We can ignore the writer check, as in our case, the reader never do update. > My understanding is that read-side operations are only used to facilitate > the quiescence detection. > the run cnt is used to decide if a thread is active (if it is currently > inside a read-side section). > the local clock is used to check if the active thread goes into the > read-side section very late, so it does not prevent reclaiming memory > unlinked before it enters the read section. > However i see no difference between RLU and RCU read-side operation > regarding consistency guarantee. > Could you kindly teach me more? In order to teach you more, I do need some help from you. I have posted a number of URLs earlier in this email thread. Could you please tell me what you learned from each of them? Thanx, Paul > BTW, the RLU read-side ops are similar, but not efficient, comparing to our > Parsec work [1, 2] > [1] Yuxin Ren, G. Liu, G. Parmer, B. Brandenburg, Scalable Memory > Reclamation for Multi-Core, Real-Time Systems, in Proceedings of the 24th > IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS), > 2018 > [2] Q. Wang, T. Stamler, and G. Parmer, Parallel Sections: Scaling > System-Level Data-Structures, in Proceedings of European Conference on > Computer Systems (EuroSys), 2016 > > Thanks, > Best, > Yuxin > > > > > This is because MVCC and RLU provide readers a consistent view of > > > > the updates, and RCU does not. Of course, it is often the case that a > > > > consistent view is not needed, in which case the MVCC and RLU > > guarantees > > > > are incurring read-side overhead for no reason. But if the use case > > > > requires consistent readers, RCU is not an option. > > > > > > > > The reason a consistent view is not always needed is that > > speed-of-light > > > > delays make it impossible to provide a consistent view of the outside > > > > world. In the common case where the use case interacts with the > > > > outside world, the algorithms absolutely must be designed to tolerate > > > > inconsistency, which opens the door to things like RCU. > > > > > > I am confused here. I think speed-of-light delays happen everywhere, not > > > only bound to RCU, but also any other synchronization approach (such > > RLU). > > > If so, how do others (RLU) provide consistent views? > > > > You just stated the answer. Now it is only necessary for you to invest > > the time, effort, and thought to fully understand it. To help with this, > > the following paragraph provides another hint: > > > > Yes, you are quite right, speed-of-light delays between the > > outside world and the computer affect RLU just as surely as they > > do RCU. This means that the additional consistency guarantees > > provided by RLU must necessarily be limited to the confines of the > > computer system in question. Taking this one step further, there > > are also speed-of-light delays within the computer. Therefore, > > in the general case, RLU can provide its consistency guarantees, > > even within the confines of the computer system, only at the > > expense of incurring delays. Because RCU does not provide RLU's > > consistency guarantees, it need not incur RLU's delays. > > > > This is not a new line of reasoning, see for example: > > > > @article{Herlihy:1996:LCN:1063369.1063372 > > ,author = {Herlihy, Maurice and Shavit, Nir and Waarts, Orli} > > ,title = {Linearizable counting networks} > > ,journal = {Distrib. Comput.} > > ,volume = {9} > > ,issue = {4} > > ,month = {February} > > ,year = {1996} > > ,issn = {0178-2770} > > ,pages = {193--203} > > ,numpages = {11} > > ,url = {http://portal.acm.org/citation.cfm?id=1063369.1063372} > > ,doi = {10.1007/s004460050019} > > ,acmid = {1063372} > > ,publisher = {Springer-Verlag} > > ,address = {London, UK} > > ,keywords = {concurrency, contention, counting networks, data structures, > > linearizability} > > } > > > > Thanx, Paul > > > > > Thanks for your education. > > > Yuxin > > > > > > > > > > > Thanx, Paul > > > > > > > > > Thanks > > > > > Yuxin > > > > > > > > > > On Fri, Dec 6, 2019 at 11:30 AM Paul E. McKenney > > > > > > wrote: > > > > > > > > > > > On Fri, Dec 06, 2019 at 10:59:05AM -0500, Mathieu Desnoyers wrote: > > > > > > > ----- On Dec 6, 2019, at 3:51 PM, Yuxin Ren > > > > wrote: > > > > > > > > > > > > > > > On Fri, Dec 6, 2019 at 5:49 AM Mathieu Desnoyers < [ > > > > > > > > mailto:mathieu.desnoyers at efficios.com | > > > > mathieu.desnoyers at efficios.com > > > > > > ] > > > > > > > > > wrote: > > > > > > > > > > > > > > >> ----- On Dec 5, 2019, at 8:17 PM, Yuxin Ren < [ mailto: > > > > > > ryx at gwmail.gwu.edu | > > > > > > > >> ryx at gwmail.gwu.edu ] > wrote: > > > > > > > > > > > > > > >>> Hi, > > > > > > > >>> I am a student, and learning RCU now, but still know very > > little > > > > > > about it. > > > > > > > >>> Are there any documents/papers/materials which (in)formally > > > > define > > > > > > and explain > > > > > > > >>> RCU consistency guarantees? > > > > > > > > > > > > > > >> You may want to have a look at > > > > > > > > > > > > > > >> User-Level Implementations of Read-Copy Update > > > > > > > >> Article in IEEE Transactions on Parallel and Distributed > > Systems > > > > > > 23(2):375 - 382 > > > > > > > >> ? March 2012 > > > > > > > > > > > > > > > Thanks for your info. > > > > > > > > However, I do not think URCU talks about any consistency model > > > > > > formally. > > > > > > > > > > > > > > > From previous communication with Paul, he said RCU is not > > designed > > > > for > > > > > > > > linearizability, and it is totally acceptable that RCU is not > > > > > > linearizable. > > > > > > > > However, I am curious how to accurately/formally Characterize > > RCU > > > > > > consistency > > > > > > > > model/guarantees > > > > > > > > > > > > > > Adding Paul E. McKenney in CC. > > > > > > > > > > > > > > I am referring to the section "Overview of RCU semantics" in the > > > > paper. > > > > > > Not sure it has the level of > > > > > > > formality you are looking for though. Paul, do you have pointers > > to > > > > > > additional material ? > > > > > > > > > > > > Indeed I do! The Linux kernel memory model (LKMM) includes RCU. > > It is > > > > > > in tools/memory-model in recent kernel source trees, which includes > > > > > > documentation. This is an executable model, which means that you > > > > > > can create litmus tests and have the model formally and > > automatically > > > > > > evaluate them. > > > > > > > > > > > > There are also a number of publications covering LKMM: > > > > > > > > > > > > o A formal kernel memory-ordering model > > > > > > https://lwn.net/Articles/718628/ > > > > > > https://lwn.net/Articles/720550/ > > > > > > > > > > > > These cover the release stores and dependency ordering that > > > > > > provide RCU's publish-subscribe guarantees. > > > > > > > > > > > > Backup material here: > > > > > > > > > > > > > > > > > > > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/ > > > > > > > > > > > > With these two likely being of particular interest: > > > > > > > > > > > > > > > > > > > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/RCUguarantees.html > > > > > > > > > > > > > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/srcu.html > > > > > > > > > > > > o Frightening Small Children and Disconcerting Grown-ups: > > > > > > Concurrency in the Linux Kernel > > > > > > https://dl.acm.org/citation.cfm?id=3177156 > > > > > > > > http://www0.cs.ucl.ac.uk/staff/j.alglave/papers/asplos18.pdf > > > > > > > > > > > > Backup material: > > > > > > > > > > > > http://diy.inria.fr/linux/ > > > > > > > > > > > > o Who's afraid of a big bad optimizing compiler? > > > > > > https://lwn.net/Articles/793253/ > > > > > > > > > > > > o Calibrating your fear of big bad optimizing compilers > > > > > > https://lwn.net/Articles/799218/ > > > > > > > > > > > > These last two justify use of normal C-language assignment > > > > > > statements to initialize and access data referenced by > > > > > > RCU-protected pointers. > > > > > > > > > > > > There is a large body of litmus tests (thousands of them) here: > > > > > > > > > > > > https://github.com/paulmckrcu/litmus > > > > > > > > > > > > Many of these litmus tests involve RCU, and these can be located by > > > > > > search for files containing rcu_read_lock(), rcu_read_unlock(), > > > > > > synchronize_rcu(), and so on. > > > > > > > > > > > > Or were you looking for something else? > > > > > > > > > > > > Thanx, Paul > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Mathieu > > > > > > > > > > > > > > >> as a starting point. > > > > > > > > > > > > > > >> Thanks, > > > > > > > > > > > > > > >> Mathieu > > > > > > > > > > > > > > >>> I know there are some consistency models in the database area > > > > (such > > > > > > as PRAM, > > > > > > > >>> Read Uncommitted, etc) from [ https://jepsen.io/consistency > > | > > > > > > > >>> https://jepsen.io/consistency ] and [1]. > > > > > > > >>> How does RCU related to those consistency models? > > > > > > > > > > > > > > >>> I also found some comments online (One key distinction is > > that > > > > both > > > > > > MVCC and RLU > > > > > > > >>> provide much stronger consistency guarantees to readers than > > does > > > > > > RCU ...) ( [ > > > > > > > >>> https://lwn.net/Articles/777036/ | > > > > https://lwn.net/Articles/777036/ > > > > > > ] ). > > > > > > > >>> I do not understand how we reason/dresibe/compare the > > consistency > > > > > > guarantees. ( > > > > > > > >>> I even do not know what consistency guarantees provided by > > RCU > > > > > > formally) > > > > > > > >>> Could someone explain this to me? > > > > > > > > > > > > > > >>> [1] Bailis, P., Davidson, A., Fekete, A., Ghodsi, A., > > > > Hellerstein, > > > > > > J. M., & > > > > > > > >>> Stoica, I. (2013). Highly available transactions: Virtues and > > > > > > limitations. > > > > > > > >>> Proceedings of the VLDB Endowment, 7(3), 181-192. > > > > > > > > > > > > > > >>> Thanks > > > > > > > >>> Yuxin > > > > > > > > > > > > > > >>> _______________________________________________ > > > > > > > >>> lttng-dev mailing list > > > > > > > >>> [ mailto:lttng-dev at lists.lttng.org | > > lttng-dev at lists.lttng.org ] > > > > > > > >>> [ https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > > | > > > > > > > >>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ] > > > > > > > > > > > > > > >> -- > > > > > > > >> Mathieu Desnoyers > > > > > > > >> EfficiOS Inc. > > > > > > > >> [ http://www.efficios.com/ | http://www.efficios.com ] > > > > > > > > > > > > > > -- > > > > > > > Mathieu Desnoyers > > > > > > > EfficiOS Inc. > > > > > > > http://www.efficios.com > > > > > > > > > > > > From ryx at gwmail.gwu.edu Sun Dec 15 17:10:11 2019 From: ryx at gwmail.gwu.edu (Yuxin Ren) Date: Sun, 15 Dec 2019 17:10:11 -0500 Subject: [lttng-dev] RCU consistency guarantees In-Reply-To: <20191215203019.GN2889@paulmck-ThinkPad-P72> References: <194534011.751.1575629349181.JavaMail.zimbra@efficios.com> <512711764.1078.1575647945136.JavaMail.zimbra@efficios.com> <20191206163052.GG2889@paulmck-ThinkPad-P72> <20191207063730.GN2889@paulmck-ThinkPad-P72> <20191207224232.GR2889@paulmck-ThinkPad-P72> <20191215203019.GN2889@paulmck-ThinkPad-P72> Message-ID: On Sun, Dec 15, 2019 at 3:30 PM Paul E. McKenney wrote: > On Sat, Dec 14, 2019 at 01:31:31AM -0500, Yuxin Ren wrote: > > Hi Paul > > > > On Sat, Dec 7, 2019 at 5:42 PM Paul E. McKenney > wrote: > > > > > On Sat, Dec 07, 2019 at 03:04:42PM -0500, Yuxin Ren wrote: > > > > Thanks a lot for your help. I have some questions below. > > > > > > > > On Sat, Dec 7, 2019 at 1:37 AM Paul E. McKenney > > > wrote: > > > > > > > > > On Fri, Dec 06, 2019 at 07:00:13PM -0500, Yuxin Ren wrote: > > > > > > Thanks so much for your great help. > > > > > > I definitely will look at those resources and papers! > > > > > > > > > > > > One more thing that I am confused > > > > > > As I mentioned earlier, someone said One key distinction is that > both > > > > > MVCC > > > > > > and RLU provide much stronger consistency guarantees to readers > than > > > does > > > > > > RCU ...) (https://lwn.net/Articles/777036/). > > > > > > > > > > That someone was in fact me. ;-) > > > > > > > > > > > I am not sure if the above statement is correct or not. But in > > > general, > > > > > > How can we compare RCU consistency guarantees to other techniques > > > (such > > > > > as > > > > > > RLU)? > > > > > > How to reason about which one has stronger or weaker guarantees? > > > > > > > > > > I suggest starting from the use case. For concreteness, let's > assume > > > > > that we are using a hash table. At one extreme, imagine a use > case in > > > > > which each event makes exactly one hash-table operation. No > > > information > > > > > is carried from one event to the next. (This might well be the > case > > > > > for simple web server.) Such a use case cannot tell the difference > > > > > between RCU on the one hand and MVCC/RLU on the other. > > > > > > > > > > At the other extreme, suppose that each event either accesses or > > > updates > > > > > multiple entries in the hash table. In this case, MVCC/RLU will > rule > > > > > out outcomes that RCU would permit. For example, suppose we had > four > > > > > events accessing two different elements in different buckets of the > > > > > hash table: > > > > > > > > > > E1: Adds 32 to the hash table. > > > > > E2: Adds 1729 to the hash table. > > > > > E3: Within a read-side critical section, looks up 32 then > 1729. > > > > > E4: Within a read-side critical section, looks up 1729 > then 32. > > > > > > > > > > Given either MVCC or RLU, it will not be possible for E3 to find > 32 but > > > > > not 1729 and at the same time for E4 to find 1729 but not 32. > Given > > > RCU, > > > > > this outcome is possible. > > > > > > > > > When you say "Within a read-side section", do you mean within a > single > > > same > > > > read section? such as > > > > > > > > > read_lock() > > > > > lookup(32) > > > > > lookup(1729) > > > > > read_unlock() > > > > > > > > > > > > How about putting two lookups into two read-side sections? Do we > still > > > have > > > > the problem, then? > > > > > > > > > read_lock() > > > > > lookup(32) > > > > > read_unlock() > > > > > read_lock() > > > > > lookup(1729) > > > > > read_unlock() > > > > > > Without in any way agreeing with your characterization of this as a > > > problem, because rcu_read_lock() and rcu_read_unlock() provide > > > absolutely no ordering guarantees in the absence of a grace period, > > > any non-grace-period-related reordering that can happen with a single > > > RCU read-side critical section can also happen when that critical > > > section is split in two as you have done above. > > > > > > > Could you kindly give me more clues why RCU can see such reorder, > while > > > RLU > > > > can prevent it? > > > > > > Here are minimal C-language implementations for RCU that can (and are) > > > actually used: > > > > > Great. We use the same thing in our real-time work [1] > > It has been a popular choice for 40 years now. ;-) > > > > #define rcu_read_lock() > > > #define rcu_read_unlock() > > > > > > Please compare these to the read-side markers presented in the RLU > paper, > > > and then tell me your thoughts on the answer to your question. ;-) > > > > > I submit my homework here, but I do not think I did it well. > > 1. I believe in the default URCU implementation, it has memory barrier > > inside the read_lock / read_unlock. > > It certainly was at one time. But you would of course need to check > to see what any given worker actually used. > > > 2. From the RLU paper, it shows the code for read-side operation. > > RLU_READER_LOCK(ctx) > > ctx.is-writer?false > > ctx.run-cnt?ctx.run-cnt+1. > > memory fence > > ctx.local-clock?global-clock > > RLU_READER_UNLOCK(ctx) > > ctx.run-cnt?ctx.run-cnt+1 > > if (ctx.is-writer) > > RLU_COMMIT_WRITE_LOG(ctx) > > > > We can ignore the writer check, as in our case, the reader never do > update. > > My understanding is that read-side operations are only used to facilitate > > the quiescence detection. > > the run cnt is used to decide if a thread is active (if it is currently > > inside a read-side section). > > the local clock is used to check if the active thread goes into the > > read-side section very late, so it does not prevent reclaiming memory > > unlinked before it enters the read section. > > However i see no difference between RLU and RCU read-side operation > > regarding consistency guarantee. > > Could you kindly teach me more? > > In order to teach you more, I do need some help from you. I have posted > a number of URLs earlier in this email thread. Could you please tell > me what you learned from each of them? > Sure, I will definitely learn those resources you provided, and come back to you if I have more questions. Simply speaking, I failed to find a clear and formal consistency model/guarantee of RCU quickly. The difficulty for me is, for most people, at their first glance, RCU only has relax/weak consistency guarantee. So whenever I suggest to use RCU to others, they always ask like Does RCU provide Serializability? .. maybe not. Does RCU provide Linearizability? ... maybe not ... OK, what does RCU provide? .. I am not sure. I even cannot find a single document which has an accurate answer. Let me give more examples. 1. When I recommend using read-write lock, people are happy to use it. However, when I further suggest to replace rw lock with RCU, then they hesitate to do so. Because they feel RCU is weaker than rw lock, and do not know what precisely RCU guarantee. 2. In contrast, in the database area, it has relative clear definition of consistency levels (such as https://jepsen.io/consistency), and users are easy to assert if they can use certain database configuration based on its consistency model. Again, I really appreciate your patience and communication, hope those does not bother you a lot. Thanks Best, Yuxin > > Thanx, Paul > > > BTW, the RLU read-side ops are similar, but not efficient, comparing to > our > > Parsec work [1, 2] > > [1] Yuxin Ren, G. Liu, G. Parmer, B. Brandenburg, Scalable Memory > > Reclamation for Multi-Core, Real-Time Systems, in Proceedings of the 24th > > IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS), > > 2018 > > [2] Q. Wang, T. Stamler, and G. Parmer, Parallel Sections: Scaling > > System-Level Data-Structures, in Proceedings of European Conference on > > Computer Systems (EuroSys), 2016 > > > > Thanks, > > Best, > > Yuxin > > > > > > > > This is because MVCC and RLU provide readers a consistent view of > > > > > the updates, and RCU does not. Of course, it is often the case > that a > > > > > consistent view is not needed, in which case the MVCC and RLU > > > guarantees > > > > > are incurring read-side overhead for no reason. But if the use > case > > > > > requires consistent readers, RCU is not an option. > > > > > > > > > > The reason a consistent view is not always needed is that > > > speed-of-light > > > > > delays make it impossible to provide a consistent view of the > outside > > > > > world. In the common case where the use case interacts with the > > > > > outside world, the algorithms absolutely must be designed to > tolerate > > > > > inconsistency, which opens the door to things like RCU. > > > > > > > > I am confused here. I think speed-of-light delays happen everywhere, > not > > > > only bound to RCU, but also any other synchronization approach (such > > > RLU). > > > > If so, how do others (RLU) provide consistent views? > > > > > > You just stated the answer. Now it is only necessary for you to invest > > > the time, effort, and thought to fully understand it. To help with > this, > > > the following paragraph provides another hint: > > > > > > Yes, you are quite right, speed-of-light delays between the > > > outside world and the computer affect RLU just as surely as > they > > > do RCU. This means that the additional consistency guarantees > > > provided by RLU must necessarily be limited to the confines of > the > > > computer system in question. Taking this one step further, > there > > > are also speed-of-light delays within the computer. Therefore, > > > in the general case, RLU can provide its consistency > guarantees, > > > even within the confines of the computer system, only at the > > > expense of incurring delays. Because RCU does not provide > RLU's > > > consistency guarantees, it need not incur RLU's delays. > > > > > > This is not a new line of reasoning, see for example: > > > > > > @article{Herlihy:1996:LCN:1063369.1063372 > > > ,author = {Herlihy, Maurice and Shavit, Nir and Waarts, Orli} > > > ,title = {Linearizable counting networks} > > > ,journal = {Distrib. Comput.} > > > ,volume = {9} > > > ,issue = {4} > > > ,month = {February} > > > ,year = {1996} > > > ,issn = {0178-2770} > > > ,pages = {193--203} > > > ,numpages = {11} > > > ,url = {http://portal.acm.org/citation.cfm?id=1063369.1063372} > > > ,doi = {10.1007/s004460050019} > > > ,acmid = {1063372} > > > ,publisher = {Springer-Verlag} > > > ,address = {London, UK} > > > ,keywords = {concurrency, contention, counting networks, data > structures, > > > linearizability} > > > } > > > > > > Thanx, Paul > > > > > > > Thanks for your education. > > > > Yuxin > > > > > > > > > > > > > > Thanx, Paul > > > > > > > > > > > Thanks > > > > > > Yuxin > > > > > > > > > > > > On Fri, Dec 6, 2019 at 11:30 AM Paul E. McKenney < > paulmck at kernel.org > > > > > > > > > wrote: > > > > > > > > > > > > > On Fri, Dec 06, 2019 at 10:59:05AM -0500, Mathieu Desnoyers > wrote: > > > > > > > > ----- On Dec 6, 2019, at 3:51 PM, Yuxin Ren < > ryx at gwmail.gwu.edu> > > > > > wrote: > > > > > > > > > > > > > > > > > On Fri, Dec 6, 2019 at 5:49 AM Mathieu Desnoyers < [ > > > > > > > > > mailto:mathieu.desnoyers at efficios.com | > > > > > mathieu.desnoyers at efficios.com > > > > > > > ] > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > >> ----- On Dec 5, 2019, at 8:17 PM, Yuxin Ren < [ mailto: > > > > > > > ryx at gwmail.gwu.edu | > > > > > > > > >> ryx at gwmail.gwu.edu ] > wrote: > > > > > > > > > > > > > > > > >>> Hi, > > > > > > > > >>> I am a student, and learning RCU now, but still know very > > > little > > > > > > > about it. > > > > > > > > >>> Are there any documents/papers/materials which > (in)formally > > > > > define > > > > > > > and explain > > > > > > > > >>> RCU consistency guarantees? > > > > > > > > > > > > > > > > >> You may want to have a look at > > > > > > > > > > > > > > > > >> User-Level Implementations of Read-Copy Update > > > > > > > > >> Article in IEEE Transactions on Parallel and Distributed > > > Systems > > > > > > > 23(2):375 - 382 > > > > > > > > >> ? March 2012 > > > > > > > > > > > > > > > > > Thanks for your info. > > > > > > > > > However, I do not think URCU talks about any consistency > model > > > > > > > formally. > > > > > > > > > > > > > > > > > From previous communication with Paul, he said RCU is not > > > designed > > > > > for > > > > > > > > > linearizability, and it is totally acceptable that RCU is > not > > > > > > > linearizable. > > > > > > > > > However, I am curious how to accurately/formally > Characterize > > > RCU > > > > > > > consistency > > > > > > > > > model/guarantees > > > > > > > > > > > > > > > > Adding Paul E. McKenney in CC. > > > > > > > > > > > > > > > > I am referring to the section "Overview of RCU semantics" in > the > > > > > paper. > > > > > > > Not sure it has the level of > > > > > > > > formality you are looking for though. Paul, do you have > pointers > > > to > > > > > > > additional material ? > > > > > > > > > > > > > > Indeed I do! The Linux kernel memory model (LKMM) includes > RCU. > > > It is > > > > > > > in tools/memory-model in recent kernel source trees, which > includes > > > > > > > documentation. This is an executable model, which means that > you > > > > > > > can create litmus tests and have the model formally and > > > automatically > > > > > > > evaluate them. > > > > > > > > > > > > > > There are also a number of publications covering LKMM: > > > > > > > > > > > > > > o A formal kernel memory-ordering model > > > > > > > https://lwn.net/Articles/718628/ > > > > > > > https://lwn.net/Articles/720550/ > > > > > > > > > > > > > > These cover the release stores and dependency ordering > that > > > > > > > provide RCU's publish-subscribe guarantees. > > > > > > > > > > > > > > Backup material here: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/ > > > > > > > > > > > > > > With these two likely being of particular interest: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/RCUguarantees.html > > > > > > > > > > > > > > > > > > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/srcu.html > > > > > > > > > > > > > > o Frightening Small Children and Disconcerting Grown-ups: > > > > > > > Concurrency in the Linux Kernel > > > > > > > https://dl.acm.org/citation.cfm?id=3177156 > > > > > > > > > > http://www0.cs.ucl.ac.uk/staff/j.alglave/papers/asplos18.pdf > > > > > > > > > > > > > > Backup material: > > > > > > > > > > > > > > http://diy.inria.fr/linux/ > > > > > > > > > > > > > > o Who's afraid of a big bad optimizing compiler? > > > > > > > https://lwn.net/Articles/793253/ > > > > > > > > > > > > > > o Calibrating your fear of big bad optimizing compilers > > > > > > > https://lwn.net/Articles/799218/ > > > > > > > > > > > > > > These last two justify use of normal C-language > assignment > > > > > > > statements to initialize and access data referenced by > > > > > > > RCU-protected pointers. > > > > > > > > > > > > > > There is a large body of litmus tests (thousands of them) here: > > > > > > > > > > > > > > https://github.com/paulmckrcu/litmus > > > > > > > > > > > > > > Many of these litmus tests involve RCU, and these can be > located by > > > > > > > search for files containing rcu_read_lock(), rcu_read_unlock(), > > > > > > > synchronize_rcu(), and so on. > > > > > > > > > > > > > > Or were you looking for something else? > > > > > > > > > > > > > > Thanx, > Paul > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > Mathieu > > > > > > > > > > > > > > > > >> as a starting point. > > > > > > > > > > > > > > > > >> Thanks, > > > > > > > > > > > > > > > > >> Mathieu > > > > > > > > > > > > > > > > >>> I know there are some consistency models in the database > area > > > > > (such > > > > > > > as PRAM, > > > > > > > > >>> Read Uncommitted, etc) from [ > https://jepsen.io/consistency > > > | > > > > > > > > >>> https://jepsen.io/consistency ] and [1]. > > > > > > > > >>> How does RCU related to those consistency models? > > > > > > > > > > > > > > > > >>> I also found some comments online (One key distinction is > > > that > > > > > both > > > > > > > MVCC and RLU > > > > > > > > >>> provide much stronger consistency guarantees to readers > than > > > does > > > > > > > RCU ...) ( [ > > > > > > > > >>> https://lwn.net/Articles/777036/ | > > > > > https://lwn.net/Articles/777036/ > > > > > > > ] ). > > > > > > > > >>> I do not understand how we reason/dresibe/compare the > > > consistency > > > > > > > guarantees. ( > > > > > > > > >>> I even do not know what consistency guarantees provided > by > > > RCU > > > > > > > formally) > > > > > > > > >>> Could someone explain this to me? > > > > > > > > > > > > > > > > >>> [1] Bailis, P., Davidson, A., Fekete, A., Ghodsi, A., > > > > > Hellerstein, > > > > > > > J. M., & > > > > > > > > >>> Stoica, I. (2013). Highly available transactions: > Virtues and > > > > > > > limitations. > > > > > > > > >>> Proceedings of the VLDB Endowment, 7(3), 181-192. > > > > > > > > > > > > > > > > >>> Thanks > > > > > > > > >>> Yuxin > > > > > > > > > > > > > > > > >>> _______________________________________________ > > > > > > > > >>> lttng-dev mailing list > > > > > > > > >>> [ mailto:lttng-dev at lists.lttng.org | > > > lttng-dev at lists.lttng.org ] > > > > > > > > >>> [ > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > > > | > > > > > > > > >>> > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ] > > > > > > > > > > > > > > > > >> -- > > > > > > > > >> Mathieu Desnoyers > > > > > > > > >> EfficiOS Inc. > > > > > > > > >> [ http://www.efficios.com/ | http://www.efficios.com ] > > > > > > > > > > > > > > > > -- > > > > > > > > Mathieu Desnoyers > > > > > > > > EfficiOS Inc. > > > > > > > > http://www.efficios.com > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paulmck at kernel.org Sun Dec 15 19:57:39 2019 From: paulmck at kernel.org (Paul E. McKenney) Date: Sun, 15 Dec 2019 16:57:39 -0800 Subject: [lttng-dev] RCU consistency guarantees In-Reply-To: References: <512711764.1078.1575647945136.JavaMail.zimbra@efficios.com> <20191206163052.GG2889@paulmck-ThinkPad-P72> <20191207063730.GN2889@paulmck-ThinkPad-P72> <20191207224232.GR2889@paulmck-ThinkPad-P72> <20191215203019.GN2889@paulmck-ThinkPad-P72> Message-ID: <20191216005739.GP2889@paulmck-ThinkPad-P72> On Sun, Dec 15, 2019 at 05:10:11PM -0500, Yuxin Ren wrote: > On Sun, Dec 15, 2019 at 3:30 PM Paul E. McKenney wrote: > > > On Sat, Dec 14, 2019 at 01:31:31AM -0500, Yuxin Ren wrote: > > > Hi Paul > > > > > > On Sat, Dec 7, 2019 at 5:42 PM Paul E. McKenney > > wrote: > > > > > > > On Sat, Dec 07, 2019 at 03:04:42PM -0500, Yuxin Ren wrote: > > > > > Thanks a lot for your help. I have some questions below. > > > > > > > > > > On Sat, Dec 7, 2019 at 1:37 AM Paul E. McKenney > > > > wrote: > > > > > > > > > > > On Fri, Dec 06, 2019 at 07:00:13PM -0500, Yuxin Ren wrote: > > > > > > > Thanks so much for your great help. > > > > > > > I definitely will look at those resources and papers! > > > > > > > > > > > > > > One more thing that I am confused > > > > > > > As I mentioned earlier, someone said One key distinction is that > > both > > > > > > MVCC > > > > > > > and RLU provide much stronger consistency guarantees to readers > > than > > > > does > > > > > > > RCU ...) (https://lwn.net/Articles/777036/). > > > > > > > > > > > > That someone was in fact me. ;-) > > > > > > > > > > > > > I am not sure if the above statement is correct or not. But in > > > > general, > > > > > > > How can we compare RCU consistency guarantees to other techniques > > > > (such > > > > > > as > > > > > > > RLU)? > > > > > > > How to reason about which one has stronger or weaker guarantees? > > > > > > > > > > > > I suggest starting from the use case. For concreteness, let's > > assume > > > > > > that we are using a hash table. At one extreme, imagine a use > > case in > > > > > > which each event makes exactly one hash-table operation. No > > > > information > > > > > > is carried from one event to the next. (This might well be the > > case > > > > > > for simple web server.) Such a use case cannot tell the difference > > > > > > between RCU on the one hand and MVCC/RLU on the other. > > > > > > > > > > > > At the other extreme, suppose that each event either accesses or > > > > updates > > > > > > multiple entries in the hash table. In this case, MVCC/RLU will > > rule > > > > > > out outcomes that RCU would permit. For example, suppose we had > > four > > > > > > events accessing two different elements in different buckets of the > > > > > > hash table: > > > > > > > > > > > > E1: Adds 32 to the hash table. > > > > > > E2: Adds 1729 to the hash table. > > > > > > E3: Within a read-side critical section, looks up 32 then > > 1729. > > > > > > E4: Within a read-side critical section, looks up 1729 > > then 32. > > > > > > > > > > > > Given either MVCC or RLU, it will not be possible for E3 to find > > 32 but > > > > > > not 1729 and at the same time for E4 to find 1729 but not 32. > > Given > > > > RCU, > > > > > > this outcome is possible. > > > > > > > > > > > When you say "Within a read-side section", do you mean within a > > single > > > > same > > > > > read section? such as > > > > > > > > > > > read_lock() > > > > > > lookup(32) > > > > > > lookup(1729) > > > > > > read_unlock() > > > > > > > > > > > > > > > How about putting two lookups into two read-side sections? Do we > > still > > > > have > > > > > the problem, then? > > > > > > > > > > > read_lock() > > > > > > lookup(32) > > > > > > read_unlock() > > > > > > read_lock() > > > > > > lookup(1729) > > > > > > read_unlock() > > > > > > > > Without in any way agreeing with your characterization of this as a > > > > problem, because rcu_read_lock() and rcu_read_unlock() provide > > > > absolutely no ordering guarantees in the absence of a grace period, > > > > any non-grace-period-related reordering that can happen with a single > > > > RCU read-side critical section can also happen when that critical > > > > section is split in two as you have done above. > > > > > > > > > Could you kindly give me more clues why RCU can see such reorder, > > while > > > > RLU > > > > > can prevent it? > > > > > > > > Here are minimal C-language implementations for RCU that can (and are) > > > > actually used: > > > > > > > Great. We use the same thing in our real-time work [1] > > > > It has been a popular choice for 40 years now. ;-) > > > > > > #define rcu_read_lock() > > > > #define rcu_read_unlock() > > > > > > > > Please compare these to the read-side markers presented in the RLU > > paper, > > > > and then tell me your thoughts on the answer to your question. ;-) > > > > > > > I submit my homework here, but I do not think I did it well. > > > 1. I believe in the default URCU implementation, it has memory barrier > > > inside the read_lock / read_unlock. > > > > It certainly was at one time. But you would of course need to check > > to see what any given worker actually used. > > > > > 2. From the RLU paper, it shows the code for read-side operation. > > > RLU_READER_LOCK(ctx) > > > ctx.is-writer?false > > > ctx.run-cnt?ctx.run-cnt+1. > > > memory fence > > > ctx.local-clock?global-clock > > > RLU_READER_UNLOCK(ctx) > > > ctx.run-cnt?ctx.run-cnt+1 > > > if (ctx.is-writer) > > > RLU_COMMIT_WRITE_LOG(ctx) > > > > > > We can ignore the writer check, as in our case, the reader never do > > update. > > > My understanding is that read-side operations are only used to facilitate > > > the quiescence detection. > > > the run cnt is used to decide if a thread is active (if it is currently > > > inside a read-side section). > > > the local clock is used to check if the active thread goes into the > > > read-side section very late, so it does not prevent reclaiming memory > > > unlinked before it enters the read section. > > > However i see no difference between RLU and RCU read-side operation > > > regarding consistency guarantee. > > > Could you kindly teach me more? > > > > In order to teach you more, I do need some help from you. I have posted > > a number of URLs earlier in this email thread. Could you please tell > > me what you learned from each of them? > > > Sure, I will definitely learn those resources you provided, and come back > to you if I have more questions. > Simply speaking, I failed to find a clear and formal consistency > model/guarantee of RCU quickly. > The difficulty for me is, for most people, at their first glance, RCU only > has relax/weak consistency guarantee. > So whenever I suggest to use RCU to others, they always ask like > Does RCU provide Serializability? .. maybe not. > Does RCU provide Linearizability? ... maybe not > ... Are serializability and linearizability always useful? Definitely not. Are serializability and linearizability expensive? You bet!!! But if your use case absolutely requires either serializability or linearizability, you probably should try something other than RCU. But you should also strongly question serializability and lineariability requirements, given that they are often imposed out of fear and force of habit rather than real need. Nevertheless, there are use cases where RCU is part of a concurrency design that provides serializability and/or linearizability. For but one example: @Conference{Arcangeli03, Author="Andrea Arcangeli and Mingming Cao and Paul E. McKenney and Dipankar Sarma", Title="Using Read-Copy Update Techniques for {System V IPC} in the {Linux} 2.5 Kernel", Booktitle="Proceedings of the 2003 USENIX Annual Technical Conference (FREENIX Track)", Publisher="USENIX Association", location="San Antonio, Texas, USA", year="2003", month="June", pages="297-310", url="https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/arcangeli/arcangeli.pdf", lastchecked="February 27, 2017", } > OK, what does RCU provide? .. I am not sure. I even cannot find a single > document which has an accurate answer. > > Let me give more examples. > 1. When I recommend using read-write lock, people are happy to use it. > However, when I further suggest to replace rw lock with RCU, then they > hesitate to do so. Because they feel RCU is weaker than rw lock, and do not > know what precisely RCU guarantee. > 2. In contrast, in the database area, it has relative clear definition of > consistency levels (such as https://jepsen.io/consistency), and users are > easy to assert if they can use certain database configuration based on its > consistency model. The RCU guarantees are clearly stated in a number of places. Most recently and most formally, the 2018 ASPLOS "Frightening small children" paper called out below (though the 2012 paper you referred to has a good and sufficient statement of its guarantees). This formalism is executable, and has been available within the Linux-kernel source tree in executable form for more than a year. I strongly recommend that you try playing with this executable model. But successfully using RCU requires that you think about your problem differently. This should not be a surprise. After all, locking provides mutual exclusion and RCU does not. So one set of promising use cases for RCU are where some quantity is calculated read-holding a reader-writer lock, but where that quantity is used after releasing that reader-writer lock. This is a common use case, and it is a case where the user has purposefully set aside the serializability and linearizability guarantees that reader-writer locking provides -- but has nevertheless paid the full price for these guarantees. > Again, I really appreciate your patience and communication, hope those does > not bother you a lot. At this point, I must confess to being much more amused than bothered. For example, do I understand correctly that you haven't yet read -any- of the references I sent you? It sure seems that way. ;-) Also, are you getting adequate sleep, as in at least seven hours per night? After all, attempting to learn RCU while sleep-deprived quite foolhardy. Thanx, Paul > Thanks > Best, > Yuxin > > > > > Thanx, Paul > > > > > BTW, the RLU read-side ops are similar, but not efficient, comparing to > > our > > > Parsec work [1, 2] > > > [1] Yuxin Ren, G. Liu, G. Parmer, B. Brandenburg, Scalable Memory > > > Reclamation for Multi-Core, Real-Time Systems, in Proceedings of the 24th > > > IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS), > > > 2018 > > > [2] Q. Wang, T. Stamler, and G. Parmer, Parallel Sections: Scaling > > > System-Level Data-Structures, in Proceedings of European Conference on > > > Computer Systems (EuroSys), 2016 > > > > > > Thanks, > > > Best, > > > Yuxin > > > > > > > > > > > This is because MVCC and RLU provide readers a consistent view of > > > > > > the updates, and RCU does not. Of course, it is often the case > > that a > > > > > > consistent view is not needed, in which case the MVCC and RLU > > > > guarantees > > > > > > are incurring read-side overhead for no reason. But if the use > > case > > > > > > requires consistent readers, RCU is not an option. > > > > > > > > > > > > The reason a consistent view is not always needed is that > > > > speed-of-light > > > > > > delays make it impossible to provide a consistent view of the > > outside > > > > > > world. In the common case where the use case interacts with the > > > > > > outside world, the algorithms absolutely must be designed to > > tolerate > > > > > > inconsistency, which opens the door to things like RCU. > > > > > > > > > > I am confused here. I think speed-of-light delays happen everywhere, > > not > > > > > only bound to RCU, but also any other synchronization approach (such > > > > RLU). > > > > > If so, how do others (RLU) provide consistent views? > > > > > > > > You just stated the answer. Now it is only necessary for you to invest > > > > the time, effort, and thought to fully understand it. To help with > > this, > > > > the following paragraph provides another hint: > > > > > > > > Yes, you are quite right, speed-of-light delays between the > > > > outside world and the computer affect RLU just as surely as > > they > > > > do RCU. This means that the additional consistency guarantees > > > > provided by RLU must necessarily be limited to the confines of > > the > > > > computer system in question. Taking this one step further, > > there > > > > are also speed-of-light delays within the computer. Therefore, > > > > in the general case, RLU can provide its consistency > > guarantees, > > > > even within the confines of the computer system, only at the > > > > expense of incurring delays. Because RCU does not provide > > RLU's > > > > consistency guarantees, it need not incur RLU's delays. > > > > > > > > This is not a new line of reasoning, see for example: > > > > > > > > @article{Herlihy:1996:LCN:1063369.1063372 > > > > ,author = {Herlihy, Maurice and Shavit, Nir and Waarts, Orli} > > > > ,title = {Linearizable counting networks} > > > > ,journal = {Distrib. Comput.} > > > > ,volume = {9} > > > > ,issue = {4} > > > > ,month = {February} > > > > ,year = {1996} > > > > ,issn = {0178-2770} > > > > ,pages = {193--203} > > > > ,numpages = {11} > > > > ,url = {http://portal.acm.org/citation.cfm?id=1063369.1063372} > > > > ,doi = {10.1007/s004460050019} > > > > ,acmid = {1063372} > > > > ,publisher = {Springer-Verlag} > > > > ,address = {London, UK} > > > > ,keywords = {concurrency, contention, counting networks, data > > structures, > > > > linearizability} > > > > } > > > > > > > > Thanx, Paul > > > > > > > > > Thanks for your education. > > > > > Yuxin > > > > > > > > > > > > > > > > > Thanx, Paul > > > > > > > > > > > > > Thanks > > > > > > > Yuxin > > > > > > > > > > > > > > On Fri, Dec 6, 2019 at 11:30 AM Paul E. McKenney < > > paulmck at kernel.org > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > On Fri, Dec 06, 2019 at 10:59:05AM -0500, Mathieu Desnoyers > > wrote: > > > > > > > > > ----- On Dec 6, 2019, at 3:51 PM, Yuxin Ren < > > ryx at gwmail.gwu.edu> > > > > > > wrote: > > > > > > > > > > > > > > > > > > > On Fri, Dec 6, 2019 at 5:49 AM Mathieu Desnoyers < [ > > > > > > > > > > mailto:mathieu.desnoyers at efficios.com | > > > > > > mathieu.desnoyers at efficios.com > > > > > > > > ] > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > >> ----- On Dec 5, 2019, at 8:17 PM, Yuxin Ren < [ mailto: > > > > > > > > ryx at gwmail.gwu.edu | > > > > > > > > > >> ryx at gwmail.gwu.edu ] > wrote: > > > > > > > > > > > > > > > > > > >>> Hi, > > > > > > > > > >>> I am a student, and learning RCU now, but still know very > > > > little > > > > > > > > about it. > > > > > > > > > >>> Are there any documents/papers/materials which > > (in)formally > > > > > > define > > > > > > > > and explain > > > > > > > > > >>> RCU consistency guarantees? > > > > > > > > > > > > > > > > > > >> You may want to have a look at > > > > > > > > > > > > > > > > > > >> User-Level Implementations of Read-Copy Update > > > > > > > > > >> Article in IEEE Transactions on Parallel and Distributed > > > > Systems > > > > > > > > 23(2):375 - 382 > > > > > > > > > >> ? March 2012 > > > > > > > > > > > > > > > > > > > Thanks for your info. > > > > > > > > > > However, I do not think URCU talks about any consistency > > model > > > > > > > > formally. > > > > > > > > > > > > > > > > > > > From previous communication with Paul, he said RCU is not > > > > designed > > > > > > for > > > > > > > > > > linearizability, and it is totally acceptable that RCU is > > not > > > > > > > > linearizable. > > > > > > > > > > However, I am curious how to accurately/formally > > Characterize > > > > RCU > > > > > > > > consistency > > > > > > > > > > model/guarantees > > > > > > > > > > > > > > > > > > Adding Paul E. McKenney in CC. > > > > > > > > > > > > > > > > > > I am referring to the section "Overview of RCU semantics" in > > the > > > > > > paper. > > > > > > > > Not sure it has the level of > > > > > > > > > formality you are looking for though. Paul, do you have > > pointers > > > > to > > > > > > > > additional material ? > > > > > > > > > > > > > > > > Indeed I do! The Linux kernel memory model (LKMM) includes > > RCU. > > > > It is > > > > > > > > in tools/memory-model in recent kernel source trees, which > > includes > > > > > > > > documentation. This is an executable model, which means that > > you > > > > > > > > can create litmus tests and have the model formally and > > > > automatically > > > > > > > > evaluate them. > > > > > > > > > > > > > > > > There are also a number of publications covering LKMM: > > > > > > > > > > > > > > > > o A formal kernel memory-ordering model > > > > > > > > https://lwn.net/Articles/718628/ > > > > > > > > https://lwn.net/Articles/720550/ > > > > > > > > > > > > > > > > These cover the release stores and dependency ordering > > that > > > > > > > > provide RCU's publish-subscribe guarantees. > > > > > > > > > > > > > > > > Backup material here: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/ > > > > > > > > > > > > > > > > With these two likely being of particular interest: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/RCUguarantees.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/srcu.html > > > > > > > > > > > > > > > > o Frightening Small Children and Disconcerting Grown-ups: > > > > > > > > Concurrency in the Linux Kernel > > > > > > > > https://dl.acm.org/citation.cfm?id=3177156 > > > > > > > > > > > > http://www0.cs.ucl.ac.uk/staff/j.alglave/papers/asplos18.pdf > > > > > > > > > > > > > > > > Backup material: > > > > > > > > > > > > > > > > http://diy.inria.fr/linux/ > > > > > > > > > > > > > > > > o Who's afraid of a big bad optimizing compiler? > > > > > > > > https://lwn.net/Articles/793253/ > > > > > > > > > > > > > > > > o Calibrating your fear of big bad optimizing compilers > > > > > > > > https://lwn.net/Articles/799218/ > > > > > > > > > > > > > > > > These last two justify use of normal C-language > > assignment > > > > > > > > statements to initialize and access data referenced by > > > > > > > > RCU-protected pointers. > > > > > > > > > > > > > > > > There is a large body of litmus tests (thousands of them) here: > > > > > > > > > > > > > > > > https://github.com/paulmckrcu/litmus > > > > > > > > > > > > > > > > Many of these litmus tests involve RCU, and these can be > > located by > > > > > > > > search for files containing rcu_read_lock(), rcu_read_unlock(), > > > > > > > > synchronize_rcu(), and so on. > > > > > > > > > > > > > > > > Or were you looking for something else? > > > > > > > > > > > > > > > > Thanx, > > Paul > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > Mathieu > > > > > > > > > > > > > > > > > > >> as a starting point. > > > > > > > > > > > > > > > > > > >> Thanks, > > > > > > > > > > > > > > > > > > >> Mathieu > > > > > > > > > > > > > > > > > > >>> I know there are some consistency models in the database > > area > > > > > > (such > > > > > > > > as PRAM, > > > > > > > > > >>> Read Uncommitted, etc) from [ > > https://jepsen.io/consistency > > > > | > > > > > > > > > >>> https://jepsen.io/consistency ] and [1]. > > > > > > > > > >>> How does RCU related to those consistency models? > > > > > > > > > > > > > > > > > > >>> I also found some comments online (One key distinction is > > > > that > > > > > > both > > > > > > > > MVCC and RLU > > > > > > > > > >>> provide much stronger consistency guarantees to readers > > than > > > > does > > > > > > > > RCU ...) ( [ > > > > > > > > > >>> https://lwn.net/Articles/777036/ | > > > > > > https://lwn.net/Articles/777036/ > > > > > > > > ] ). > > > > > > > > > >>> I do not understand how we reason/dresibe/compare the > > > > consistency > > > > > > > > guarantees. ( > > > > > > > > > >>> I even do not know what consistency guarantees provided > > by > > > > RCU > > > > > > > > formally) > > > > > > > > > >>> Could someone explain this to me? > > > > > > > > > > > > > > > > > > >>> [1] Bailis, P., Davidson, A., Fekete, A., Ghodsi, A., > > > > > > Hellerstein, > > > > > > > > J. M., & > > > > > > > > > >>> Stoica, I. (2013). Highly available transactions: > > Virtues and > > > > > > > > limitations. > > > > > > > > > >>> Proceedings of the VLDB Endowment, 7(3), 181-192. > > > > > > > > > > > > > > > > > > >>> Thanks > > > > > > > > > >>> Yuxin > > > > > > > > > > > > > > > > > > >>> _______________________________________________ > > > > > > > > > >>> lttng-dev mailing list > > > > > > > > > >>> [ mailto:lttng-dev at lists.lttng.org | > > > > lttng-dev at lists.lttng.org ] > > > > > > > > > >>> [ > > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > > > > | > > > > > > > > > >>> > > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ] > > > > > > > > > > > > > > > > > > >> -- > > > > > > > > > >> Mathieu Desnoyers > > > > > > > > > >> EfficiOS Inc. > > > > > > > > > >> [ http://www.efficios.com/ | http://www.efficios.com ] > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Mathieu Desnoyers > > > > > > > > > EfficiOS Inc. > > > > > > > > > http://www.efficios.com > > > > > > > > > > > > > > > > > > > > From yogesh.chandolia at globallogic.com Mon Dec 16 02:09:33 2019 From: yogesh.chandolia at globallogic.com (Yogesh Chandolia) Date: Mon, 16 Dec 2019 12:39:33 +0530 Subject: [lttng-dev] Regarding LTTNG support for Containers Message-ID: Hi Team, We are planning to use LTTng2.11 for tracing the application in user-space using the LTTng-UST library only. Our application will run in the container. We have query regarding the support of LTTng-UST for the containerize environment. Please let us know whether LTTng support the tracing for containerize application. If yes, please share the documentation of LTTng-UST support for container environment. Thanks & Regards, Yogesh Mobile: +91 9910094311 Email: yogesh.chandolia at globallogic.com Skype ID: yogesh.chandolia at globalogicindia.onmicrosoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.rajotte-julien at efficios.com Mon Dec 16 10:40:13 2019 From: jonathan.rajotte-julien at efficios.com (Jonathan Rajotte-Julien) Date: Mon, 16 Dec 2019 10:40:13 -0500 Subject: [lttng-dev] Regarding LTTNG support for Containers In-Reply-To: References: Message-ID: <20191216154013.GB29567@joraj-alpa> Hi, On Mon, Dec 16, 2019 at 12:39:33PM +0530, Yogesh Chandolia via lttng-dev wrote: > Hi Team, > > > > We are planning to use LTTng2.11 for tracing the application in user-space > using the LTTng-UST library only. Our application will run in the > container. Where do you plan on running the session daemon and consumer daemon? > > We have query regarding the support of LTTng-UST for the containerize > environment. > > Please let us know whether LTTng support the tracing for containerize > application. If yes, please share the documentation of LTTng-UST support > for container environment. > > > Thanks & Regards, > > Yogesh > > Mobile: +91 9910094311 > > Email: yogesh.chandolia at globallogic.com > > Skype ID: yogesh.chandolia at globalogicindia.onmicrosoft.com > _______________________________________________ > lttng-dev mailing list > lttng-dev at lists.lttng.org > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Jonathan Rajotte-Julien EfficiOS From walbroel at silexica.com Tue Dec 17 03:56:46 2019 From: walbroel at silexica.com (Florian Walbroel) Date: Tue, 17 Dec 2019 09:56:46 +0100 Subject: [lttng-dev] Fwd: [PATCH lttng-modules] Add UDP and ICMP packet header information to the tracepoint: In-Reply-To: <20191113163814.31606-1-walbroel@silexica.com> References: <20191113163814.31606-1-walbroel@silexica.com> Message-ID: <7b697030-2d01-90bf-0225-fe52b42e9cd0@silexica.com> Hi, I sent in this patch last month and did not hear about any updates since then. There were a few formatting issues that have been addressed. Is there anything more that should be done? Best regards, Florian Walbroel -------- Forwarded Message -------- Subject: [PATCH lttng-modules] Add UDP and ICMP packet header information to the tracepoint: Date: Wed, 13 Nov 2019 17:38:14 +0100 From: Florian Walbroel To: lttng-dev at lists.lttng.org * UDP transport header * ICMP transport header (Correct indentation for switch/case) Signed-off-by: Florian Walbroel --- instrumentation/events/lttng-module/net.h | 166 ++++++++++++++++++++-- 1 file changed, 153 insertions(+), 13 deletions(-) diff --git a/instrumentation/events/lttng-module/net.h b/instrumentation/events/lttng-module/net.h index bfa14fc..ad1892a 100644 --- a/instrumentation/events/lttng-module/net.h +++ b/instrumentation/events/lttng-module/net.h @@ -11,6 +11,8 @@ #include #include #include +#include +#include #include #include #include @@ -85,6 +87,53 @@ static struct lttng_event_field tcpfields[] = { }, }; +static struct lttng_event_field udpfields[] = { + [0] = { + .name = "source_port", + .type = __type_integer(uint16_t, 0, 0, 0, + __BIG_ENDIAN, 10, none), + }, + [1] = { + .name = "dest_port", + .type = __type_integer(uint16_t, 0, 0, 0, + __BIG_ENDIAN, 10, none), + }, + [2] = { + .name = "len", + .type = __type_integer(uint16_t, 0, 0, 0, + __BIG_ENDIAN, 10, none), + }, + [3] = { + .name = "check", + .type = __type_integer(uint16_t, 0, 0, 0, + __BIG_ENDIAN, 10, none), + }, +}; + +static struct lttng_event_field icmpfields[] = { + [0] = { + .name = "type", + .type = __type_integer(uint8_t, 0, 0, 0, + __BIG_ENDIAN, 10, none), + }, + [1] = { + .name = "code", + .type = __type_integer(uint8_t, 0, 0, 0, + __BIG_ENDIAN, 10, none), + }, + [2] = { + .name = "checksum", + .type = __type_integer(uint16_t, 0, 0, 0, + __BIG_ENDIAN, 10, none), + }, + [3] = { + .name = "gateway", + .type = __type_integer(uint32_t, 0, 0, 0, + __BIG_ENDIAN, 10, none), + }, +}; + + static struct lttng_event_field transport_fields[] = { [0] = { .name = "unknown", @@ -102,13 +151,57 @@ static struct lttng_event_field transport_fields[] = { .u._struct.fields = tcpfields, }, }, + [2] = { + .name = "udp", + .type = { + .atype = atype_struct, + .u._struct.nr_fields = ARRAY_SIZE(udpfields), + .u._struct.fields = udpfields, + }, + }, + [3] = { + .name = "icmp", + .type = { + .atype = atype_struct, + .u._struct.nr_fields = ARRAY_SIZE(icmpfields), + .u._struct.fields = icmpfields, + }, + }, }; enum transport_header_types { TH_NONE = 0, TH_TCP = 1, + TH_UDP = 2, + TH_ICMP = 3, }; +static inline enum transport_header_types __get_transport_header_type_ip(struct sk_buff *skb) +{ + switch(ip_hdr(skb)->protocol) { + case IPPROTO_TCP: + return TH_TCP; + case IPPROTO_UDP: + return TH_UDP; + case IPPROTO_ICMP: + return TH_ICMP; + } + return TH_NONE; +} + +static inline enum transport_header_types __get_transport_header_type_ipv6(struct sk_buff *skb) +{ + switch(ipv6_hdr(skb)->nexthdr) { + case IPPROTO_TCP: + return TH_TCP; + case IPPROTO_UDP: + return TH_UDP; + case IPPROTO_ICMP: + return TH_ICMP; + } + return TH_NONE; +} + static inline enum transport_header_types __get_transport_header_type(struct sk_buff *skb) { if (__has_network_hdr(skb)) { @@ -123,13 +216,13 @@ static inline enum transport_header_types __get_transport_header_type(struct sk_ * header's data. This method works both for * sent and received packets. */ - if ((skb->protocol == htons(ETH_P_IP) && - ip_hdr(skb)->protocol == IPPROTO_TCP) || - (skb->protocol == htons(ETH_P_IPV6) && - ipv6_hdr(skb)->nexthdr == IPPROTO_TCP)) - return TH_TCP; + if (skb->protocol == htons(ETH_P_IP)) { + return __get_transport_header_type_ip(skb); + } else if(skb->protocol == htons(ETH_P_IPV6)) { + return __get_transport_header_type_ipv6(skb); + } } - /* Fallthrough for other cases where header is not TCP. */ + /* Fallthrough for other cases where header is not recognized. */ } return TH_NONE; } @@ -137,16 +230,36 @@ static inline enum transport_header_types __get_transport_header_type(struct sk_ static struct lttng_enum_entry proto_transport_enum_entries[] = { [0] = { .start = { .value = 0, .signedness = 0, }, - .end = { .value = IPPROTO_TCP - 1, .signedness = 0, }, + .end = { .value = IPPROTO_ICMP - 1, .signedness = 0, }, .string = "_unknown", }, [1] = { + .start = { .value = IPPROTO_ICMP, .signedness = 0, }, + .end = { .value = IPPROTO_ICMP, .signedness = 0, }, + .string = "_icmp", + }, + [2] = { + .start = { .value = IPPROTO_ICMP + 1, .signedness = 0, }, + .end = { .value = IPPROTO_TCP - 1, .signedness = 0, }, + .string = "_unknown", + }, + [3] = { .start = { .value = IPPROTO_TCP, .signedness = 0, }, .end = { .value = IPPROTO_TCP, .signedness = 0, }, .string = "_tcp", }, - [2] = { + [4] = { .start = { .value = IPPROTO_TCP + 1, .signedness = 0, }, + .end = { .value = IPPROTO_UDP - 1, .signedness = 0, }, + .string = "_unknown", + }, + [5] = { + .start = { .value = IPPROTO_UDP, .signedness = 0, }, + .end = { .value = IPPROTO_UDP, .signedness = 0, }, + .string = "_udp", + }, + [6] = { + .start = { .value = IPPROTO_UDP + 1, .signedness = 0, }, .end = { .value = 255, .signedness = 0, }, .string = "_unknown", }, @@ -169,6 +282,16 @@ static struct lttng_enum_entry transport_enum_entries[] = { .end = { .value = TH_TCP, .signedness = 0, }, .string = "_tcp", }, + [2] = { + .start = { .value = TH_UDP, .signedness = 0, }, + .end = { .value = TH_UDP, .signedness = 0, }, + .string = "_udp", + }, + [3] = { + .start = { .value = TH_ICMP, .signedness = 0, }, + .end = { .value = TH_ICMP, .signedness = 0, }, + .string = "_icmp", + }, }; static const struct lttng_enum_desc transport_header_type = { @@ -510,15 +633,32 @@ LTTNG_TRACEPOINT_EVENT_CLASS(net_dev_template, ctf_integer_type(unsigned char, th_type) /* Copy the transport header. */ - if (th_type == TH_TCP) { + switch (th_type) { + case TH_TCP: { ctf_align(uint32_t) ctf_array_type(uint8_t, tcp_hdr(skb), sizeof(struct tcphdr)) + break; + } + case TH_UDP: { + ctf_align(uint32_t) + ctf_array_type(uint8_t, udp_hdr(skb), + sizeof(struct udphdr)) + break; + } + case TH_ICMP: { + ctf_align(uint32_t) + ctf_array_type(uint8_t, icmp_hdr(skb), + sizeof(struct udphdr)) + break; + } + default: + /* + * For any other transport header type, + * there is nothing to do. + */ + break; } - /* - * For any other transport header type, - * there is nothing to do. - */ } ) ) -- 2.17.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.desnoyers at efficios.com Tue Dec 17 09:39:51 2019 From: mathieu.desnoyers at efficios.com (Mathieu Desnoyers) Date: Tue, 17 Dec 2019 09:39:51 -0500 (EST) Subject: [lttng-dev] Fwd: [PATCH lttng-modules] Add UDP and ICMP packet header information to the tracepoint: In-Reply-To: <7b697030-2d01-90bf-0225-fe52b42e9cd0@silexica.com> References: <20191113163814.31606-1-walbroel@silexica.com> <7b697030-2d01-90bf-0225-fe52b42e9cd0@silexica.com> Message-ID: <1666401048.8323.1576593591017.JavaMail.zimbra@efficios.com> ----- On Dec 17, 2019, at 3:56 AM, Florian Walbroel wrote: > Hi, > I sent in this patch last month and did not hear about any updates since then. > There were a few formatting issues that have been addressed. Is there anything > more that should be done? Hi, I was expecting review from Genevi?ve and Julien on this patch, but never heard back from them. Genevi?ve, Julien, Michael, can you review this patch please ? Thanks, Mathieu > Best regards, > Florian Walbroel > -------- Forwarded Message -------- Subject: [PATCH lttng-modules] Add UDP and > ICMP packet header information to the tracepoint: > Date: Wed, 13 Nov 2019 17:38:14 +0100 > From: Florian Walbroel [ mailto:walbroel at silexica.com | > ] > To: [ mailto:lttng-dev at lists.lttng.org | lttng-dev at lists.lttng.org ] > * UDP transport header > * ICMP transport header > (Correct indentation for switch/case) > Signed-off-by: Florian Walbroel [ mailto:walbroel at silexica.com | > ] > --- > instrumentation/events/lttng-module/net.h | 166 ++++++++++++++++++++-- > 1 file changed, 153 insertions(+), 13 deletions(-) > diff --git a/instrumentation/events/lttng-module/net.h > b/instrumentation/events/lttng-module/net.h > index bfa14fc..ad1892a 100644 > --- a/instrumentation/events/lttng-module/net.h > +++ b/instrumentation/events/lttng-module/net.h > @@ -11,6 +11,8 @@ > #include > #include > #include > +#include > +#include > #include > #include > #include > @@ -85,6 +87,53 @@ static struct lttng_event_field tcpfields[] = { > }, > }; > +static struct lttng_event_field udpfields[] = { > + [0] = { > + .name = "source_port", > + .type = __type_integer(uint16_t, 0, 0, 0, > + __BIG_ENDIAN, 10, none), > + }, > + [1] = { > + .name = "dest_port", > + .type = __type_integer(uint16_t, 0, 0, 0, > + __BIG_ENDIAN, 10, none), > + }, > + [2] = { > + .name = "len", > + .type = __type_integer(uint16_t, 0, 0, 0, > + __BIG_ENDIAN, 10, none), > + }, > + [3] = { > + .name = "check", > + .type = __type_integer(uint16_t, 0, 0, 0, > + __BIG_ENDIAN, 10, none), > + }, > +}; > + > +static struct lttng_event_field icmpfields[] = { > + [0] = { > + .name = "type", > + .type = __type_integer(uint8_t, 0, 0, 0, > + __BIG_ENDIAN, 10, none), > + }, > + [1] = { > + .name = "code", > + .type = __type_integer(uint8_t, 0, 0, 0, > + __BIG_ENDIAN, 10, none), > + }, > + [2] = { > + .name = "checksum", > + .type = __type_integer(uint16_t, 0, 0, 0, > + __BIG_ENDIAN, 10, none), > + }, > + [3] = { > + .name = "gateway", > + .type = __type_integer(uint32_t, 0, 0, 0, > + __BIG_ENDIAN, 10, none), > + }, > +}; > + > + > static struct lttng_event_field transport_fields[] = { > [0] = { > .name = "unknown", > @@ -102,13 +151,57 @@ static struct lttng_event_field transport_fields[] = { > .u._struct.fields = tcpfields, > }, > }, > + [2] = { > + .name = "udp", > + .type = { > + .atype = atype_struct, > + .u._struct.nr_fields = ARRAY_SIZE(udpfields), > + .u._struct.fields = udpfields, > + }, > + }, > + [3] = { > + .name = "icmp", > + .type = { > + .atype = atype_struct, > + .u._struct.nr_fields = ARRAY_SIZE(icmpfields), > + .u._struct.fields = icmpfields, > + }, > + }, > }; > enum transport_header_types { > TH_NONE = 0, > TH_TCP = 1, > + TH_UDP = 2, > + TH_ICMP = 3, > }; > +static inline enum transport_header_types __get_transport_header_type_ip(struct > sk_buff *skb) > +{ > + switch(ip_hdr(skb)->protocol) { > + case IPPROTO_TCP: > + return TH_TCP; > + case IPPROTO_UDP: > + return TH_UDP; > + case IPPROTO_ICMP: > + return TH_ICMP; > + } > + return TH_NONE; > +} > + > +static inline enum transport_header_types > __get_transport_header_type_ipv6(struct sk_buff *skb) > +{ > + switch(ipv6_hdr(skb)->nexthdr) { > + case IPPROTO_TCP: > + return TH_TCP; > + case IPPROTO_UDP: > + return TH_UDP; > + case IPPROTO_ICMP: > + return TH_ICMP; > + } > + return TH_NONE; > +} > + > static inline enum transport_header_types __get_transport_header_type(struct > sk_buff *skb) > { > if (__has_network_hdr(skb)) { > @@ -123,13 +216,13 @@ static inline enum transport_header_types > __get_transport_header_type(struct sk_ > * header's data. This method works both for > * sent and received packets. > */ > - if ((skb->protocol == htons(ETH_P_IP) && > - ip_hdr(skb)->protocol == IPPROTO_TCP) || > - (skb->protocol == htons(ETH_P_IPV6) && > - ipv6_hdr(skb)->nexthdr == IPPROTO_TCP)) > - return TH_TCP; > + if (skb->protocol == htons(ETH_P_IP)) { > + return __get_transport_header_type_ip(skb); > + } else if(skb->protocol == htons(ETH_P_IPV6)) { > + return __get_transport_header_type_ipv6(skb); > + } > } > - /* Fallthrough for other cases where header is not TCP. */ > + /* Fallthrough for other cases where header is not recognized. */ > } > return TH_NONE; > } > @@ -137,16 +230,36 @@ static inline enum transport_header_types > __get_transport_header_type(struct sk_ > static struct lttng_enum_entry proto_transport_enum_entries[] = { > [0] = { > .start = { .value = 0, .signedness = 0, }, > - .end = { .value = IPPROTO_TCP - 1, .signedness = 0, }, > + .end = { .value = IPPROTO_ICMP - 1, .signedness = 0, }, > .string = "_unknown", > }, > [1] = { > + .start = { .value = IPPROTO_ICMP, .signedness = 0, }, > + .end = { .value = IPPROTO_ICMP, .signedness = 0, }, > + .string = "_icmp", > + }, > + [2] = { > + .start = { .value = IPPROTO_ICMP + 1, .signedness = 0, }, > + .end = { .value = IPPROTO_TCP - 1, .signedness = 0, }, > + .string = "_unknown", > + }, > + [3] = { > .start = { .value = IPPROTO_TCP, .signedness = 0, }, > .end = { .value = IPPROTO_TCP, .signedness = 0, }, > .string = "_tcp", > }, > - [2] = { > + [4] = { > .start = { .value = IPPROTO_TCP + 1, .signedness = 0, }, > + .end = { .value = IPPROTO_UDP - 1, .signedness = 0, }, > + .string = "_unknown", > + }, > + [5] = { > + .start = { .value = IPPROTO_UDP, .signedness = 0, }, > + .end = { .value = IPPROTO_UDP, .signedness = 0, }, > + .string = "_udp", > + }, > + [6] = { > + .start = { .value = IPPROTO_UDP + 1, .signedness = 0, }, > .end = { .value = 255, .signedness = 0, }, > .string = "_unknown", > }, > @@ -169,6 +282,16 @@ static struct lttng_enum_entry transport_enum_entries[] = { > .end = { .value = TH_TCP, .signedness = 0, }, > .string = "_tcp", > }, > + [2] = { > + .start = { .value = TH_UDP, .signedness = 0, }, > + .end = { .value = TH_UDP, .signedness = 0, }, > + .string = "_udp", > + }, > + [3] = { > + .start = { .value = TH_ICMP, .signedness = 0, }, > + .end = { .value = TH_ICMP, .signedness = 0, }, > + .string = "_icmp", > + }, > }; > static const struct lttng_enum_desc transport_header_type = { > @@ -510,15 +633,32 @@ LTTNG_TRACEPOINT_EVENT_CLASS(net_dev_template, > ctf_integer_type(unsigned char, th_type) > /* Copy the transport header. */ > - if (th_type == TH_TCP) { > + switch (th_type) { > + case TH_TCP: { > ctf_align(uint32_t) > ctf_array_type(uint8_t, tcp_hdr(skb), > sizeof(struct tcphdr)) > + break; > + } > + case TH_UDP: { > + ctf_align(uint32_t) > + ctf_array_type(uint8_t, udp_hdr(skb), > + sizeof(struct udphdr)) > + break; > + } > + case TH_ICMP: { > + ctf_align(uint32_t) > + ctf_array_type(uint8_t, icmp_hdr(skb), > + sizeof(struct udphdr)) > + break; > + } > + default: > + /* > + * For any other transport header type, > + * there is nothing to do. > + */ > + break; > } > - /* > - * For any other transport header type, > - * there is nothing to do. > - */ > } > ) > ) > -- > 2.17.1 > _______________________________________________ > 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 -------------- An HTML attachment was scrubbed... URL: From mjeanson at efficios.com Tue Dec 17 12:11:10 2019 From: mjeanson at efficios.com (Michael Jeanson) Date: Tue, 17 Dec 2019 12:11:10 -0500 Subject: [lttng-dev] [PATCH lttng-modules] fix: function prototype in wrapper/mm.h Message-ID: <20191217171111.6782-1-mjeanson@efficios.com> Signed-off-by: Michael Jeanson --- wrapper/mm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wrapper/mm.h b/wrapper/mm.h index 672855b..405248a 100644 --- a/wrapper/mm.h +++ b/wrapper/mm.h @@ -62,7 +62,7 @@ void wrapper_set_current_oom_origin(void) } static inline -void wrapper_clear_current_oom_origin() +void wrapper_clear_current_oom_origin(void) { return; } -- 2.17.1 From mjeanson at efficios.com Tue Dec 17 12:11:11 2019 From: mjeanson at efficios.com (Michael Jeanson) Date: Tue, 17 Dec 2019 12:11:11 -0500 Subject: [lttng-dev] [PATCH lttng-modules] fix: use user ns wrapper code in new id trackers In-Reply-To: <20191217171111.6782-1-mjeanson@efficios.com> References: <20191217171111.6782-1-mjeanson@efficios.com> Message-ID: <20191217171111.6782-2-mjeanson@efficios.com> These wrappers are required to translate kuid on kernels prior to v3.5. Signed-off-by: Michael Jeanson --- probes/lttng-tracepoint-event-impl.h | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/probes/lttng-tracepoint-event-impl.h b/probes/lttng-tracepoint-event-impl.h index 39454fb..321cdfa 100644 --- a/probes/lttng-tracepoint-event-impl.h +++ b/probes/lttng-tracepoint-event-impl.h @@ -11,7 +11,6 @@ #include #include #include -#include #include #include @@ -20,6 +19,7 @@ #include #include #include +#include #include #include #include @@ -1146,19 +1146,19 @@ static void __event_probe__##_name(void *__data, _proto) \ return; \ __lf = lttng_rcu_dereference(__session->uid_tracker.p); \ if (__lf && likely(!lttng_id_tracker_lookup(__lf, \ - from_kuid(&init_user_ns, current_uid())))) \ + lttng_current_uid()))) \ return; \ __lf = lttng_rcu_dereference(__session->vuid_tracker.p); \ if (__lf && likely(!lttng_id_tracker_lookup(__lf, \ - from_kuid(current_user_ns(), current_uid())))) \ + lttng_current_vuid()))) \ return; \ __lf = lttng_rcu_dereference(__session->gid_tracker.p); \ if (__lf && likely(!lttng_id_tracker_lookup(__lf, \ - from_kgid(&init_user_ns, current_gid())))) \ + lttng_current_gid()))) \ return; \ __lf = lttng_rcu_dereference(__session->vgid_tracker.p); \ if (__lf && likely(!lttng_id_tracker_lookup(__lf, \ - from_kgid(current_user_ns(), current_gid())))) \ + lttng_current_vgid()))) \ return; \ __orig_dynamic_len_offset = this_cpu_ptr(<tng_dynamic_len_stack)->offset; \ __dynamic_len_idx = __orig_dynamic_len_offset; \ @@ -1239,19 +1239,19 @@ static void __event_probe__##_name(void *__data) \ return; \ __lf = lttng_rcu_dereference(__session->uid_tracker.p); \ if (__lf && likely(!lttng_id_tracker_lookup(__lf, \ - from_kuid(&init_user_ns, current_uid())))) \ + lttng_current_uid()))) \ return; \ __lf = lttng_rcu_dereference(__session->vuid_tracker.p); \ if (__lf && likely(!lttng_id_tracker_lookup(__lf, \ - from_kuid(current_user_ns(), current_uid())))) \ + lttng_current_vuid()))) \ return; \ __lf = lttng_rcu_dereference(__session->gid_tracker.p); \ if (__lf && likely(!lttng_id_tracker_lookup(__lf, \ - from_kgid(&init_user_ns, current_gid())))) \ + lttng_current_gid()))) \ return; \ __lf = lttng_rcu_dereference(__session->vgid_tracker.p); \ if (__lf && likely(!lttng_id_tracker_lookup(__lf, \ - from_kgid(current_user_ns(), current_gid())))) \ + lttng_current_vgid()))) \ return; \ __orig_dynamic_len_offset = this_cpu_ptr(<tng_dynamic_len_stack)->offset; \ __dynamic_len_idx = __orig_dynamic_len_offset; \ -- 2.17.1 From mjeanson at efficios.com Tue Dec 17 12:20:46 2019 From: mjeanson at efficios.com (Michael Jeanson) Date: Tue, 17 Dec 2019 12:20:46 -0500 Subject: [lttng-dev] Fwd: [PATCH lttng-modules] Add UDP and ICMP packet header information to the tracepoint: In-Reply-To: <1666401048.8323.1576593591017.JavaMail.zimbra@efficios.com> References: <20191113163814.31606-1-walbroel@silexica.com> <7b697030-2d01-90bf-0225-fe52b42e9cd0@silexica.com> <1666401048.8323.1576593591017.JavaMail.zimbra@efficios.com> Message-ID: <88c1b057-e920-433e-77b0-03dd04cd14de@efficios.com> On 2019-12-17 9:39 a.m., Mathieu Desnoyers wrote: > I was expecting review from Genevi?ve and Julien on this patch, but > never heard back from > them. > > Genevi?ve, Julien, Michael, can you review this patch please ? > > Thanks, > > Mathieu It builds on all the latest tags of the stable kernel branches we support and the patch itself looks good to me but Genevi?ve's or Julien's feedback would be appreciated. Michael From mathieu.desnoyers at efficios.com Tue Dec 17 12:23:24 2019 From: mathieu.desnoyers at efficios.com (Mathieu Desnoyers) Date: Tue, 17 Dec 2019 12:23:24 -0500 (EST) Subject: [lttng-dev] [PATCH lttng-modules] fix: function prototype in wrapper/mm.h In-Reply-To: <20191217171111.6782-1-mjeanson@efficios.com> References: <20191217171111.6782-1-mjeanson@efficios.com> Message-ID: <1699019764.8836.1576603404679.JavaMail.zimbra@efficios.com> Merged into master, 2.11, 2.10, thanks! Mathieu ----- On Dec 17, 2019, at 12:11 PM, Michael Jeanson mjeanson at efficios.com wrote: > Signed-off-by: Michael Jeanson > --- > wrapper/mm.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/wrapper/mm.h b/wrapper/mm.h > index 672855b..405248a 100644 > --- a/wrapper/mm.h > +++ b/wrapper/mm.h > @@ -62,7 +62,7 @@ void wrapper_set_current_oom_origin(void) > } > > static inline > -void wrapper_clear_current_oom_origin() > +void wrapper_clear_current_oom_origin(void) > { > return; > } > -- > 2.17.1 -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com From mathieu.desnoyers at efficios.com Tue Dec 17 12:23:33 2019 From: mathieu.desnoyers at efficios.com (Mathieu Desnoyers) Date: Tue, 17 Dec 2019 12:23:33 -0500 (EST) Subject: [lttng-dev] [PATCH lttng-modules] fix: use user ns wrapper code in new id trackers In-Reply-To: <20191217171111.6782-2-mjeanson@efficios.com> References: <20191217171111.6782-1-mjeanson@efficios.com> <20191217171111.6782-2-mjeanson@efficios.com> Message-ID: <1879153712.8837.1576603413126.JavaMail.zimbra@efficios.com> Merged into master, thanks! Mathieu ----- On Dec 17, 2019, at 12:11 PM, Michael Jeanson mjeanson at efficios.com wrote: > These wrappers are required to translate kuid on kernels prior to v3.5. > > Signed-off-by: Michael Jeanson > --- > probes/lttng-tracepoint-event-impl.h | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/probes/lttng-tracepoint-event-impl.h > b/probes/lttng-tracepoint-event-impl.h > index 39454fb..321cdfa 100644 > --- a/probes/lttng-tracepoint-event-impl.h > +++ b/probes/lttng-tracepoint-event-impl.h > @@ -11,7 +11,6 @@ > #include > #include > #include > -#include > > #include > #include > @@ -20,6 +19,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -1146,19 +1146,19 @@ static void __event_probe__##_name(void *__data, _proto) > \ > return; \ > __lf = lttng_rcu_dereference(__session->uid_tracker.p); \ > if (__lf && likely(!lttng_id_tracker_lookup(__lf, \ > - from_kuid(&init_user_ns, current_uid())))) \ > + lttng_current_uid()))) \ > return; \ > __lf = lttng_rcu_dereference(__session->vuid_tracker.p); \ > if (__lf && likely(!lttng_id_tracker_lookup(__lf, \ > - from_kuid(current_user_ns(), current_uid())))) \ > + lttng_current_vuid()))) \ > return; \ > __lf = lttng_rcu_dereference(__session->gid_tracker.p); \ > if (__lf && likely(!lttng_id_tracker_lookup(__lf, \ > - from_kgid(&init_user_ns, current_gid())))) \ > + lttng_current_gid()))) \ > return; \ > __lf = lttng_rcu_dereference(__session->vgid_tracker.p); \ > if (__lf && likely(!lttng_id_tracker_lookup(__lf, \ > - from_kgid(current_user_ns(), current_gid())))) \ > + lttng_current_vgid()))) \ > return; \ > __orig_dynamic_len_offset = this_cpu_ptr(<tng_dynamic_len_stack)->offset; \ > __dynamic_len_idx = __orig_dynamic_len_offset; \ > @@ -1239,19 +1239,19 @@ static void __event_probe__##_name(void *__data) > \ > return; \ > __lf = lttng_rcu_dereference(__session->uid_tracker.p); \ > if (__lf && likely(!lttng_id_tracker_lookup(__lf, \ > - from_kuid(&init_user_ns, current_uid())))) \ > + lttng_current_uid()))) \ > return; \ > __lf = lttng_rcu_dereference(__session->vuid_tracker.p); \ > if (__lf && likely(!lttng_id_tracker_lookup(__lf, \ > - from_kuid(current_user_ns(), current_uid())))) \ > + lttng_current_vuid()))) \ > return; \ > __lf = lttng_rcu_dereference(__session->gid_tracker.p); \ > if (__lf && likely(!lttng_id_tracker_lookup(__lf, \ > - from_kgid(&init_user_ns, current_gid())))) \ > + lttng_current_gid()))) \ > return; \ > __lf = lttng_rcu_dereference(__session->vgid_tracker.p); \ > if (__lf && likely(!lttng_id_tracker_lookup(__lf, \ > - from_kgid(current_user_ns(), current_gid())))) \ > + lttng_current_vgid()))) \ > return; \ > __orig_dynamic_len_offset = this_cpu_ptr(<tng_dynamic_len_stack)->offset; \ > __dynamic_len_idx = __orig_dynamic_len_offset; \ > -- > 2.17.1 -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com From yogesh.chandolia at globallogic.com Thu Dec 19 01:41:38 2019 From: yogesh.chandolia at globallogic.com (Yogesh Chandolia) Date: Thu, 19 Dec 2019 12:11:38 +0530 Subject: [lttng-dev] Regarding LTTNG support for Containers In-Reply-To: <20191216154013.GB29567@joraj-alpa> References: <20191216154013.GB29567@joraj-alpa> Message-ID: <4753e17ff492cb712eb9f7e14f950e9d@mail.gmail.com> Hi Jonathan, We are planning to run the session daemon and consumer daemon from the host machine to fetch the trace points of application run inside container. Thanks & Regards, Yogesh Mobile: +91 9910094311 Email: yogesh.chandolia at globallogic.com Skype ID: yogesh.chandolia at globalogicindia.onmicrosoft.com -----Original Message----- From: Jonathan Rajotte-Julien Sent: Monday, December 16, 2019 9:10 PM To: Yogesh Chandolia Cc: lttng-dev at lists.lttng.org; pratham.p.kumar at ericsson.com; Ankur Dauneria Subject: Re: [lttng-dev] Regarding LTTNG support for Containers Hi, On Mon, Dec 16, 2019 at 12:39:33PM +0530, Yogesh Chandolia via lttng-dev wrote: > Hi Team, > > > > We are planning to use LTTng2.11 for tracing the application in > user-space using the LTTng-UST library only. Our application will run > in the container. Where do you plan on running the session daemon and consumer daemon? > > We have query regarding the support of LTTng-UST for the containerize > environment. > > Please let us know whether LTTng support the tracing for containerize > application. If yes, please share the documentation of LTTng-UST > support for container environment. > > > Thanks & Regards, > > Yogesh > > Mobile: +91 9910094311 > > Email: yogesh.chandolia at globallogic.com > > Skype ID: yogesh.chandolia at globalogicindia.onmicrosoft.com > _______________________________________________ > lttng-dev mailing list > lttng-dev at lists.lttng.org > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Jonathan Rajotte-Julien EfficiOS From jeremie.galarneau at efficios.com Thu Dec 19 22:11:51 2019 From: jeremie.galarneau at efficios.com (=?UTF-8?q?J=C3=A9r=C3=A9mie=20Galarneau?=) Date: Thu, 19 Dec 2019 22:11:51 -0500 Subject: [lttng-dev] [RFC Patch] Bump LTTNG_MODULES_ABI_MINOR_VERSION to 5 Message-ID: <20191220031151.34539-1-jeremie.galarneau@efficios.com> New operations were added to the lttng-modules ABI as part of the 2.12 release cycle to support UID tracking and the "session clear" functionality. This will allow future LTTng-tools versions to check for those capabilities. Signed-off-by: J?r?mie Galarneau --- lttng-abi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lttng-abi.h b/lttng-abi.h index 5c5d825..1d356ab 100644 --- a/lttng-abi.h +++ b/lttng-abi.h @@ -17,7 +17,7 @@ * should be increased when an incompatible ABI change is done. */ #define LTTNG_MODULES_ABI_MAJOR_VERSION 2 -#define LTTNG_MODULES_ABI_MINOR_VERSION 4 +#define LTTNG_MODULES_ABI_MINOR_VERSION 5 #define LTTNG_KERNEL_SYM_NAME_LEN 256 #define LTTNG_KERNEL_SESSION_NAME_LEN 256 -- 2.24.1 From mathieu.desnoyers at efficios.com Fri Dec 20 10:47:23 2019 From: mathieu.desnoyers at efficios.com (Mathieu Desnoyers) Date: Fri, 20 Dec 2019 10:47:23 -0500 (EST) Subject: [lttng-dev] [RFC Patch] Bump LTTNG_MODULES_ABI_MINOR_VERSION to 5 In-Reply-To: <20191220031151.34539-1-jeremie.galarneau@efficios.com> References: <20191220031151.34539-1-jeremie.galarneau@efficios.com> Message-ID: <1175145214.13982.1576856843252.JavaMail.zimbra@efficios.com> Pushed into lttng-modules master. You will want to update src/common/kernel-ctl/kernel-ioctl.h in lttng-tools as well to keep those files in sync. Thanks, Mathieu ----- On Dec 19, 2019, at 10:11 PM, Jeremie Galarneau jeremie.galarneau at efficios.com wrote: > New operations were added to the lttng-modules ABI as part of the 2.12 > release cycle to support UID tracking and the "session clear" > functionality. > > This will allow future LTTng-tools versions to check for those > capabilities. > > Signed-off-by: J?r?mie Galarneau > --- > lttng-abi.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lttng-abi.h b/lttng-abi.h > index 5c5d825..1d356ab 100644 > --- a/lttng-abi.h > +++ b/lttng-abi.h > @@ -17,7 +17,7 @@ > * should be increased when an incompatible ABI change is done. > */ > #define LTTNG_MODULES_ABI_MAJOR_VERSION 2 > -#define LTTNG_MODULES_ABI_MINOR_VERSION 4 > +#define LTTNG_MODULES_ABI_MINOR_VERSION 5 > > #define LTTNG_KERNEL_SYM_NAME_LEN 256 > #define LTTNG_KERNEL_SESSION_NAME_LEN 256 > -- > 2.24.1 -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com From mathieu.desnoyers at efficios.com Fri Dec 20 10:55:45 2019 From: mathieu.desnoyers at efficios.com (Mathieu Desnoyers) Date: Fri, 20 Dec 2019 10:55:45 -0500 (EST) Subject: [lttng-dev] LTTng-UST: Bump LTTNG_UST_ABI_MINOR_VERSION to 1 Message-ID: <1817839556.13991.1576857345582.JavaMail.zimbra@efficios.com> FYI, a similar approach should be taken for lttng-ust 2.12, as pushed into the master branch: commit 677423ebf26cc17916bddd0334b1a9f7614035c9 Author: Mathieu Desnoyers Date: Fri Dec 20 10:49:20 2019 -0500 Bump LTTNG_UST_ABI_MINOR_VERSION to 1 Increment the minor version of lttng-ust ABI to 1, to take into account that the "clear" command was added in this release cycle. This will allow future LTTng-tools versions to check for this capability. Signed-off-by: Mathieu Desnoyers -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com From yogesh.chandolia at globallogic.com Tue Dec 24 05:55:28 2019 From: yogesh.chandolia at globallogic.com (Yogesh Chandolia) Date: Tue, 24 Dec 2019 16:25:28 +0530 Subject: [lttng-dev] Regarding LTTNG support for Containers In-Reply-To: 4753e17ff492cb712eb9f7e14f950e9d@mail.gmail.com References: <20191216154013.GB29567@joraj-alpa> 4753e17ff492cb712eb9f7e14f950e9d@mail.gmail.com Message-ID: <2680f7625c171abf820330c2261f109d@mail.gmail.com> Hi Jonathan, Please share your input on this. Thanks & Regards, Yogesh Mobile: +91 9910094311 Email: yogesh.chandolia at globallogic.com Skype ID: yogesh.chandolia at globalogicindia.onmicrosoft.com -----Original Message----- From: Yogesh Chandolia Sent: Thursday, December 19, 2019 12:12 PM To: 'Jonathan Rajotte-Julien' Cc: 'lttng-dev at lists.lttng.org' ; 'pratham.p.kumar at ericsson.com' ; 'Ankur Dauneria' Subject: RE: [lttng-dev] Regarding LTTNG support for Containers Hi Jonathan, We are planning to run the session daemon and consumer daemon from the host machine to fetch the trace points of application run inside container. Thanks & Regards, Yogesh Mobile: +91 9910094311 Email: yogesh.chandolia at globallogic.com Skype ID: yogesh.chandolia at globalogicindia.onmicrosoft.com -----Original Message----- From: Jonathan Rajotte-Julien Sent: Monday, December 16, 2019 9:10 PM To: Yogesh Chandolia Cc: lttng-dev at lists.lttng.org; pratham.p.kumar at ericsson.com; Ankur Dauneria Subject: Re: [lttng-dev] Regarding LTTNG support for Containers Hi, On Mon, Dec 16, 2019 at 12:39:33PM +0530, Yogesh Chandolia via lttng-dev wrote: > Hi Team, > > > > We are planning to use LTTng2.11 for tracing the application in > user-space using the LTTng-UST library only. Our application will run > in the container. Where do you plan on running the session daemon and consumer daemon? > > We have query regarding the support of LTTng-UST for the containerize > environment. > > Please let us know whether LTTng support the tracing for containerize > application. If yes, please share the documentation of LTTng-UST > support for container environment. > > > Thanks & Regards, > > Yogesh > > Mobile: +91 9910094311 > > Email: yogesh.chandolia at globallogic.com > > Skype ID: yogesh.chandolia at globalogicindia.onmicrosoft.com > _______________________________________________ > lttng-dev mailing list > lttng-dev at lists.lttng.org > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Jonathan Rajotte-Julien EfficiOS