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