From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 87234C433B4 for ; Thu, 1 Apr 2021 15:02:27 +0000 (UTC) Received: from lists.lttng.org (lists.lttng.org [167.114.26.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8674D61364 for ; Thu, 1 Apr 2021 15:02:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8674D61364 Authentication-Results: mail.kernel.org; dmarc=pass (p=none dis=none) header.from=lists.lttng.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lttng-dev-bounces@lists.lttng.org Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4FB5y83zvkzSvj; Thu, 1 Apr 2021 11:02:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1617289345; bh=ZHIi/WlnEwKszHj7audL6BWzWsdzXfXx1M5hZZb2sfs=; h=References:In-Reply-To:Date:To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=YFEeqrOrygnNXA2MTkFGVjX6UJ/HWAxgy24S3/qdCU8xg7I5GkgqIiG8ZNyhgckgC aPXaWbCEOf5AJ0uyPzxVlTiuM/xUCRJsF7J/YSL5YuMkcojrxLDCOugD0C24kVPUAk SygKbQuHiR7v/T+bCAndFyoUAEd2f/u7taxbWtb2K4BIH+HVH080NEp0hc0U0Yj7li P+50Uf3g2Oq1dGQmYfbkpWDxf8EHif9QGFhMmPfL155XXdEs4p1OTgPSovUF+sE0Bl 1izv93Miz9fRBxZBQyBh/Q0WDVTc/KAHZXUKsJWxXOiqi66CqqFTuaX5je+QxbFuC0 K3R+/1Ydrs8QA== Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) by lists.lttng.org (Postfix) with ESMTPS id 4FB5y62WgJzT1Y for ; Thu, 1 Apr 2021 11:02:22 -0400 (EDT) Received: by mail-io1-xd36.google.com with SMTP id x17so2521866iog.2 for ; Thu, 01 Apr 2021 08:02:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3WDF7NfmD/rbghHsKgADt9NoGhSeBRKOc8zDs48F5Is=; b=gIMZTKZMZmAKxsB+C7kteLqLisoa71ZK1r4ke2foxWEN7eXG2Eu3XofZuxXR7edb1g M6BOgdZ8Eng/awoq4aH6DTZ+fgiSV1j3DClhAzRHVlhZYemDV0eHgzbup9oX7fVjnLjT iS+OrRJ2XjjZOUIz8SihGgjKT9o4kyIjVhLOUc0gB51OSFZB6EEpnsBiYjOHVwX/U4SE HpJ7a1eCR/auW+YCA/3ra5bUSzySFnyXUlwi4FVjMg9rbvR/8gINueKI1rUD1pgY6Ass o5EvRYQVC73jccILmo8XsCbmoLUHVkVXETiLho2NBOdQwZOgMdtL9n6loaMTzDLcz6WE n6sA== X-Gm-Message-State: AOAM5323UnpJyzL40SimI8J9ikInZgJnE8Xf7J6ZR0f8TuOatlQEAAyR DWI1y68OnOoubAEElCczbElI+1V3q7rBWkgD4Ow= X-Google-Smtp-Source: ABdhPJygE/tv8vMaQCzlEhZBtrNRgvSC0SJL/KOZcPVRhM3vcl9ch5N7OuaodgwpDF0RAP127fj4PqbjugtamObV5ok= X-Received: by 2002:a02:a809:: with SMTP id f9mr8312271jaj.63.1617289341549; Thu, 01 Apr 2021 08:02:21 -0700 (PDT) MIME-Version: 1.0 References: <20210331185624.406960-1-wallinux@gmail.com> <592114658.48857.1617218709305.JavaMail.zimbra@efficios.com> <20210331213313.GD28307@joraj-alpa> <20210401134527.GA79283@joraj-alpa> In-Reply-To: <20210401134527.GA79283@joraj-alpa> Date: Thu, 1 Apr 2021 17:02:09 +0200 Message-ID: To: Jonathan Rajotte-Julien Cc: lttng-dev Subject: Re: [lttng-dev] [PATCH lttng-tools] Fix: test code assumes that child process is schedule to run before parent X-BeenThere: lttng-dev@lists.lttng.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: LTTng development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Anders Wallin via lttng-dev Reply-To: Anders Wallin Content-Type: multipart/mixed; boundary="===============4962648184078771564==" Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" --===============4962648184078771564== Content-Type: multipart/alternative; boundary="000000000000b3bfeb05beea84b1" --000000000000b3bfeb05beea84b1 Content-Type: text/plain; charset="UTF-8" Hi, I think you understood what I meant. The issue I have is for this 4 test cases in ./regression/tools/tracker/test_event_tracker - test_event_vpid_tracker ust 0 "${EVENT_NAME}" - test_event_vpid_track_untrack ust 0 "${EVENT_NAME}" - test_event_pid_tracker ust 0 "${EVENT_NAME}" - test_event_pid_track_untrack ust 0 "${EVENT_NAME}" I have 2 patches ready, but I want to run some more tests first before posting them Anders Wallin On Thu, Apr 1, 2021 at 3:45 PM Jonathan Rajotte-Julien < jonathan.rajotte-julien@efficios.com> wrote: > On Thu, Apr 01, 2021 at 03:21:10AM +0200, Anders Wallin wrote: > > Hi Jonathan :) > > > > It's very unlikely that the race could occur, BUT it can happen. > > > > OK run > > 1. test_event_tracker starts gen-ust-events > > 2. test_event_tracker waits for gen-ust-events to create AFTER_FIRST_PATH > > 3. gen-ust-event create first event and create AFTER_FIRST_PATH > > 4. gen-ust-event continue and create 99 events > > 5. gen-ust-event wait for BEFORE_LAST_PATH > > 6. test_event_track start collecting events (lttng start .....) > > > 7. test_event_tracker calls "lttng track ... -pid "Faulty PID" > > 8. test_event_tracker touches BEFORE_LAST_PATH > > 9. gen-ust-events creates the last event > > 10. test_event finishes and since it tracks the faulty pid the result > will > > be 0 events == OK > > The sequence of event for the `test_event_tracker` function is (as of > master): > > create > enable event > start > track > > launch app > wait for app return > stop > destroy > > > The sequence you are describing here is: > > lauch app > start > track > ... > > I'm pretty sure we are not talking about the same things. Please specify > the > test case and all functions involved and make sure to use the proper name > for > each of them. > > I suspect you are talking about test_event_pid_tracker. Still let's make > sure of > it. If it is, I do agree that it seems to have a window where we can gather > event for. > > You might want to look if there is a real reason for this sequence instead > of > mimicking test_event_tracker > > Current code: > enable_"$domain"_lttng_event_ok $SESSION_NAME "$wildcard" "$channel" > prepare_"$domain"_app > start_lttng_tracing_ok > > if [ "$expect_event" -eq 1 ]; then > lttng_track_"$domain"_ok "--vpid ${CHILD_PID}" > else > lttng_track_"$domain"_ok "--vpid $((CHILD_PID+1))" > fi > trace_"$domain"_app > stop_lttng_tracing_ok > destroy_lttng_session_ok $SESSION_NAME > > > We might simply want to move the track command before the start > considering have > all the information to do so. > > enable_"$domain"_lttng_event_ok $SESSION_NAME "$wildcard" "$channel" > > prepare_"$domain"_app > > if [ "$expect_event" -eq 1 ]; then > lttng_track_"$domain"_ok "--vpid ${CHILD_PID}" > else > lttng_track_"$domain"_ok "--vpid $((CHILD_PID+1))" > fi > > start_lttng_tracing_ok > trace_"$domain"_app > > stop_lttng_tracing_ok > destroy_lttng_session_ok $SESSION_NAME > > After testing this, seems like the validate_trace_empty does not handle the > case were simply stream allocation did not take place since no application > was > 'valid' at the moment of the trace start. > > Well we got a good one here. We will wait for your updated patch and go > from > there. > > Cheers > > > > > Faulty run > > 1. test_event_tracker starts gen-ust-events > > 2. test_event_tracker waits for gen-ust-events to create AFTER_FIRST_PATH > > 3. gen-ust-event create first event and create AFTER_FIRST_PATH > > 4. gen-ust-event gets rescheduled before it has created 99 events, e.g > > after 9 events > > 5. test_event_track start collecting events (lttng start .....) > > 6. gen-ust-event is rescheduled and starts generating the remaining > events. > > 90 events > > 7. lttng collects these 90 events since we have not setup "tracking" of > PID > > yet > > 8. test_event_tracker calls "lttng track ... -pid "Faulty PID" > > 9. test_event_tracker touches BEFORE_LAST_PATH > > 10. gen-ust-events creates the last event > > 11. test_event finishes and since it tracks the faulty pid the result > > should be 0 events, but we got 90 == FAULTY > > > > We can solve this by; > > A: using NR_ITER=2 > > or > > B: by adding a flag to gen-ust-events to wait before sending the first > event > > 1. test_event_tracker starts gen-ust-events > > 2. test_event_tracker waits for gen-ust-events waits for > BEFORE_FIRST_PATH > > 3. test_event_track start collecting events (lttng start .....) > > 4. test_event_tracker calls "lttng track ... -pid "Faulty PID" > > 5. test_event_track creates BEFORE_FIRST_PATH > > 6. gen_ust_event creates 100 events > > 7. test_event_tracker waits for gen_event_ust to end > > 8. test_event finishes and since it tracked the faulty pid the result > will > > be 0 events == OK > > > > This is in principle how gen-kernel-test-events works (but with different > > arguments) > > I would suggest to use B since that will be bulletproof > > > > Anders Wallin > > > > > > On Wed, Mar 31, 2021 at 11:33 PM Jonathan Rajotte-Julien < > > jonathan.rajotte-julien@efficios.com> wrote: > > > > > Hi, > > > > > > On Wed, Mar 31, 2021 at 11:09:42PM +0200, Anders Wallin wrote: > > > > Hi Julian, > > > > > > You can use Jonathan. ;) > > > > > > > > > > > Neither mine "sleep 0.1" or your version with "while [! -f > ............" > > > > are race condition free. > > > > > > I might be missing something here but as far as I understand the race > you > > > are > > > trying to mitigate is that the test script execute/continue before the > > > `backgrounded` > > > command (background test app) had time to execute, right? > > > > > > If so at least waiting for the app to create a file is necessary. Now > > > gen_kernel_test_events does not have this functionality. The > > > PATH_WAIT_FILE is > > > used to control when the testapp can continue. Hence the script still > > > cannot > > > know if the app have been scheduled. > > > > > > Now based on the test case you might need more synchronization for the > test > > > cases. > > > > > > Note that in the ust cases, the trace_ust_app uses `touch > > > "$BEFORE_LAST_PATH"` > > > that effectively unblock the app and allows it to perform the last > > > tracepoint > > > hit and the we `wait` on the background process. > > > > > > Note: some tests case are a bit clever and uses "trace_"$domain"_app" > > > instead of > > > calling trace_ust_app directly. > > > > > > For these tests case it seems that we are only expecting at least a > single > > > event > > > matching the event name under test. Here the last tracepoint hit should > > > satisfy > > > this criteria. > > > > > > Am I missing a race? > > > > > > Cheers > > > > > > > > > > I suggest that we add an option to gen-ust-events to wait before the > > > first > > > > event is generated. > > > > gen_kernel_test_events already have this functionality to wait > before the > > > > first event. > > > > > > > > Something like this > > > > static struct option long_options[] = > > > > { > > > > /* These options set a flag. */ > > > > {"iter", required_argument, 0, 'i'}, > > > > {"wait", required_argument, 0, 'w'}, > > > > {"sync-after-first-event", required_argument, 0, 'a'}, > > > > {"sync-before-last-event", required_argument, 0, 'b'}, > > > > {"sync-before-last-event-touch", required_argument, 0, 'c'}, > > > > {"sync-before-exit", required_argument, 0, 'd'}, > > > > {"sync-before-exit-touch", required_argument, 0, 'e'}, > > > > *+ {"sync-before-first-event", required_argument, 0, 'f'},* > > > > > > > > {0, 0, 0, 0} > > > > }; > > > > .... > > > > > > > > I will create one or more patches for this tomorrow > > > > > > > > Anders Wallin > > > > > > > > > > > > On Wed, Mar 31, 2021 at 9:25 PM Jonathan Rajotte-Julien < > > > > jonathan.rajotte-julien@efficios.com> wrote: > > > > > > > > > > # > > > > > > # SPDX-License-Identifier: GPL-2.0-only > > > > > > > > > > > > -TEST_DESC="LTTng - Event traker test" > > > > > > +TEST_DESC="LTTng - Event tracker test" > > > > > > > > > > > > CURDIR=$(dirname "$0")/ > > > > > > TESTDIR="$CURDIR/../../.." > > > > > > @@ -42,6 +42,8 @@ function prepare_ust_app > > > > > > > > > > > > $TESTAPP_BIN -i $NR_ITER -w $NR_USEC_WAIT -a > > > "$AFTER_FIRST_PATH" -b > > > > > > "$BEFORE_LAST_PATH" & > > > > > > CHILD_PID=$! > > > > > > + # voluntary context switch to start $TESTAPP_BIN > > > > > > + sleep 0.1 > > > > > > > > > > A wait on the $AFTER_FIRST_PATH file would be probably more > > > deterministic > > > > > than a sleep here. > > > > > > > > > > while [ ! -f "${AFTER_FIRST_PATH}" ]; do > > > > > sleep 0.1 > > > > > done > > > > > > > > > > I would also expect something similar for the `prepare_kernel_app` > > > > > function considering the same race is most probably present and > simply > > > not > > > > > triggered by a chance of luck. > > > > > Seems like gen-kernel-test-events does not expose the same sync > > > > > capabilities here, please use gen-ust-events as an example of how > it is > > > > > done. > > > > > > > > > > Let us know how your testing goes. > > > > > > > > > > Thanks > > > > > > > > > > > -- > > > Jonathan Rajotte-Julien > > > EfficiOS > > > > > -- > Jonathan Rajotte-Julien > EfficiOS > --000000000000b3bfeb05beea84b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I think you unders= tood what I meant. The issue I have is for this 4 test cases in=C2=A0./regr= ession/tools/tracker/test_event_tracker
- test_event_vpid_tracker= ust 0 "${EVENT_NAME}"
- test_event_vpid_track_untrack ust 0 &= quot;${EVENT_NAME}"
- test_event_pid_tracker ust 0 "${EVENT_NA= ME}"
- test_event_pid_track_untrack ust 0 "${EVENT_NAME}"=

I have 2 patches ready, but I want to run some more test= s first before posting them
=C2=A0
Anders W= allin


On Thu, Apr 1, 2021 at 3:45 PM Jonathan Rajotte-= Julien <jonathan= .rajotte-julien@efficios.com> wrote:
On Thu, Apr 01, 2021 at 03:21:10AM +0200, Ander= s Wallin wrote:
> Hi Jonathan :)
>
> It's very unlikely that the race could occur, BUT it can happen. >
> OK run
> 1. test_event_tracker starts gen-ust-events
> 2. test_event_tracker waits for gen-ust-events to create AFTER_FIRST_P= ATH
> 3. gen-ust-event create first event and create AFTER_FIRST_PATH
> 4. gen-ust-event continue and create 99 events
> 5. gen-ust-event wait for=C2=A0 BEFORE_LAST_PATH
> 6. test_event_track start collecting events (lttng start .....)

> 7. test_event_tracker calls "lttng track ... -pid "Faulty PI= D"
> 8. test_event_tracker touches BEFORE_LAST_PATH
> 9. gen-ust-events creates the last event
> 10. test_event finishes and since it tracks the faulty pid the result = will
> be 0 events =3D=3D OK

The sequence of event for the `test_event_tracker` function is (as of maste= r):

create
enable event
start
track

launch app
wait for app return
stop
destroy


The sequence you are describing here is:

lauch app
start
track
...

I'm pretty sure we are not talking about the same things. Please specif= y the
test case and all functions involved and make sure to use the proper name f= or
each of them.

I suspect you are talking about test_event_pid_tracker. Still let's mak= e sure of
it. If it is, I do agree that it seems to have a window where we can gather=
event for.

You might want to look if there is a real reason for this sequence instead = of
mimicking test_event_tracker

Current code:
=C2=A0enable_"$domain"_lttng_event_ok $SESSION_NAME "$wildca= rd" "$channel"
=C2=A0prepare_"$domain"_app
=C2=A0start_lttng_tracing_ok

=C2=A0if [ "$expect_event" -eq 1 ]; then
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lttng_track_"$domain"_ok "= --vpid ${CHILD_PID}"
=C2=A0else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lttng_track_"$domain"_ok "= --vpid $((CHILD_PID+1))"
=C2=A0fi
=C2=A0trace_"$domain"_app
=C2=A0stop_lttng_tracing_ok
=C2=A0destroy_lttng_session_ok $SESSION_NAME


We might simply want to move the track command before the start considering= have
all the information to do so.

=C2=A0enable_"$domain"_lttng_event_ok $SESSION_NAME "$wildca= rd" "$channel"

=C2=A0prepare_"$domain"_app

=C2=A0if [ "$expect_event" -eq 1 ]; then
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lttng_track_"$domain"_ok "= --vpid ${CHILD_PID}"
=C2=A0else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lttng_track_"$domain"_ok "= --vpid $((CHILD_PID+1))"
=C2=A0fi

=C2=A0start_lttng_tracing_ok
=C2=A0trace_"$domain"_app

=C2=A0stop_lttng_tracing_ok
=C2=A0destroy_lttng_session_ok $SESSION_NAME

After testing this, seems like the validate_trace_empty does not handle the=
case were simply stream allocation did not take place since no application = was
'valid' at the moment of the trace start.

Well we got a good one here. We will wait for your updated patch and go fro= m
there.

Cheers

>
> Faulty run
> 1. test_event_tracker starts gen-ust-events
> 2. test_event_tracker waits for gen-ust-events to create AFTER_FIRST_P= ATH
> 3. gen-ust-event create first event and create AFTER_FIRST_PATH
> 4. gen-ust-event gets rescheduled before it has created 99 events, e.g=
> after 9 events
> 5. test_event_track start collecting events (lttng start .....)
> 6. gen-ust-event is rescheduled and starts generating the remaining ev= ents.
> 90 events
> 7. lttng collects these 90 events since we have not setup "tracki= ng" of PID
> yet
> 8. test_event_tracker calls "lttng track ... -pid "Faulty PI= D"
> 9. test_event_tracker touches BEFORE_LAST_PATH
> 10. gen-ust-events creates the last event
> 11. test_event finishes and since it tracks the faulty pid the result<= br> > should=C2=A0 be 0 events, but we got 90 =3D=3D FAULTY
>
> We can solve this by;
> A: using NR_ITER=3D2
> or
> B: by adding a flag to gen-ust-events to wait before sending the first= event
> 1. test_event_tracker starts gen-ust-events
> 2. test_event_tracker waits for gen-ust-events waits for BEFORE_FIRST_= PATH
> 3. test_event_track start collecting events (lttng start .....)
> 4. test_event_tracker calls "lttng track ... -pid "Faulty PI= D"
> 5. test_event_track creates BEFORE_FIRST_PATH
> 6. gen_ust_event creates 100 events
> 7. test_event_tracker waits for gen_event_ust to end
> 8. test_event finishes and since it tracked the faulty pid the result = will
> be 0 events =3D=3D OK
>
> This is in principle how gen-kernel-test-events works (but with differ= ent
> arguments)
> I would suggest to use B since that will be bulletproof
>
> Anders Wallin
>
>
> On Wed, Mar 31, 2021 at 11:33 PM Jonathan Rajotte-Julien <
> jonathan.rajotte-julien@efficios.com> wrote:
>
> > Hi,
> >
> > On Wed, Mar 31, 2021 at 11:09:42PM +0200, Anders Wallin wrote: > > > Hi Julian,
> >
> > You can use Jonathan. ;)
> >
> > >
> > > Neither mine "sleep 0.1" or your version with &quo= t;while [! -f ............"
> > > are race condition free.
> >
> > I might be missing something here but as far as I understand the = race you
> > are
> > trying to mitigate is that the test script execute/continue befor= e the
> > `backgrounded`
> > command (background test app) had time to execute, right?
> >
> > If so at least waiting for the app to create a file is necessary.= Now
> > gen_kernel_test_events does not have this functionality. The
> > PATH_WAIT_FILE is
> > used to control when the testapp can continue. Hence the script s= till
> > cannot
> > know if the app have been scheduled.
> >
> > Now based on the test case you might need more synchronization fo= r the test
> > cases.
> >
> > Note that in the ust cases, the trace_ust_app uses `touch
> > "$BEFORE_LAST_PATH"`
> > that effectively unblock the app and allows it to perform the las= t
> > tracepoint
> > hit and the we `wait` on the background process.
> >
> > Note: some tests case are a bit clever and uses "trace_"= ;$domain"_app"
> > instead of
> > calling trace_ust_app directly.
> >
> > For these tests case it seems that we are only expecting at least= a single
> > event
> > matching the event name under test. Here the last tracepoint hit = should
> > satisfy
> > this criteria.
> >
> > Am I missing a race?
> >
> > Cheers
> >
> >
> > > I suggest that we add an option to gen-ust-events to wait be= fore the
> > first
> > > event is generated.
> > > gen_kernel_test_events already have this functionality to wa= it before the
> > > first event.
> > >
> > > Something like this
> > > static struct option long_options[] =3D
> > > {
> > > /* These options set a flag. */
> > > {"iter", required_argument, 0, 'i'},
> > > {"wait", required_argument, 0, 'w'},
> > > {"sync-after-first-event", required_argument, 0, &= #39;a'},
> > > {"sync-before-last-event", required_argument, 0, &= #39;b'},
> > > {"sync-before-last-event-touch", required_argument= , 0, 'c'},
> > > {"sync-before-exit", required_argument, 0, 'd&= #39;},
> > > {"sync-before-exit-touch", required_argument, 0, &= #39;e'},
> > > *+ {"sync-before-first-event", required_argument, = 0, 'f'},*
> > >
> > > {0, 0, 0, 0}
> > > };
> > > ....
> > >
> > > I will create one or more patches for this tomorrow
> > >
> > > Anders Wallin
> > >
> > >
> > > On Wed, Mar 31, 2021 at 9:25 PM Jonathan Rajotte-Julien <=
> > > jonathan.rajotte-julien@efficios.com> wrote:
> > >
> > > > > #
> > > > > # SPDX-License-Identifier: GPL-2.0-only
> > > > >
> > > > > -TEST_DESC=3D"LTTng - Event traker test"=
> > > > > +TEST_DESC=3D"LTTng - Event tracker test"= ;
> > > > >
> > > > > CURDIR=3D$(dirname "$0")/
> > > > > TESTDIR=3D"$CURDIR/../../.."
> > > > > @@ -42,6 +42,8 @@ function prepare_ust_app
> > > > >
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0$TESTAPP_BIN -i $NR_ITER= -w $NR_USEC_WAIT -a
> > "$AFTER_FIRST_PATH" -b
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0"$BEFORE_LAST_PATH&= quot; &
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0CHILD_PID=3D$!
> > > > > +=C2=A0 =C2=A0 =C2=A0# voluntary context switch to= start $TESTAPP_BIN
> > > > > +=C2=A0 =C2=A0 =C2=A0sleep 0.1
> > > >
> > > > A wait on the $AFTER_FIRST_PATH file would be probably = more
> > deterministic
> > > > than a sleep here.
> > > >
> > > >=C2=A0 =C2=A0while [ ! -f "${AFTER_FIRST_PATH}"= ; ]; do
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sleep 0.1
> > > >=C2=A0 =C2=A0done
> > > >
> > > > I would also expect something similar for the `prepare_= kernel_app`
> > > > function considering the same race is most probably pre= sent and simply
> > not
> > > > triggered by a chance of luck.
> > > > Seems like gen-kernel-test-events does not expose the s= ame sync
> > > > capabilities here, please use gen-ust-events as an exam= ple of how it is
> > > > done.
> > > >
> > > > Let us know how your testing goes.
> > > >
> > > > Thanks
> > > >
> >
> > --
> > Jonathan Rajotte-Julien
> > EfficiOS
> >

--
Jonathan Rajotte-Julien
EfficiOS
--000000000000b3bfeb05beea84b1-- --===============4962648184078771564== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev --===============4962648184078771564==--