All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Shuah Khan <shuah@kernel.org>,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-rt-users@vger.kernel.org, joseph.salisbury@canonical.com,
	Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH v2] selftests/ftrace: Do not trace do_softirq because of PREEMPT_RT
Date: Thu, 10 Feb 2022 10:05:35 -0500	[thread overview]
Message-ID: <20220210100535.01ad4978@gandalf.local.home> (raw)
In-Reply-To: <429dd2fd-3ceb-6780-f970-4ea9b115388c@canonical.com>

On Thu, 10 Feb 2022 15:13:15 +0100
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> wrote:

  
> >> The implementation detail is that do_softirq() is in ifndef.  
> > 
> > So let me ask again.  We have
> >    FUNC1="schedule"
> >    FUNC2="do_softirq"
> > 
> > What is the purpose of this? Do you need FUNC2 when ksoftirqd is run or
> > when softirqs are served? Not sure how scheduler_tick fits in all this.  
> 
> I guess this is more a question to the author of the test. Unless you
> are now questioning the entire purpose of this test?

The test is just a smoke test on function triggers. These two functions
have various triggers attached to them to see if it causes any harm (the
test was added after some strange bugs happened in the past).

Now, if "_printk" worked, it suggests that I need to look into this test
because I'm guessing _printk would never trigger during the test. The
reason we picked schedule and do_softirq was to get triggers in different
contexts (do_softirq was in the softirq context, and schedule is in the
normal context). The reason I suggested to pick "schedule_tick" is because
that should happen in the interrupt context.

But if _printk worked, then it probably didn't test that part. But that's a
different bug than what this patch is addressing.

Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

And I need to add to my TODO list, to look at this test and probably
rewrite. it. :-p

-- Steve

      parent reply	other threads:[~2022-02-10 15:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-10  8:33 [PATCH v2] selftests/ftrace: Do not trace do_softirq because of PREEMPT_RT Krzysztof Kozlowski
2022-02-10 13:47 ` Sebastian Andrzej Siewior
2022-02-10 14:05   ` Krzysztof Kozlowski
2022-02-10 14:10     ` Sebastian Andrzej Siewior
2022-02-10 14:13       ` Krzysztof Kozlowski
2022-02-10 14:48         ` Sebastian Andrzej Siewior
2022-02-10 15:07           ` Steven Rostedt
2022-02-10 15:05         ` Steven Rostedt [this message]

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20220210100535.01ad4978@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=bigeasy@linutronix.de \
    --cc=joseph.salisbury@canonical.com \
    --cc=krzysztof.kozlowski@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=shuah@kernel.org \
    --cc=skhan@linuxfoundation.org \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.