From: Krzysztof Kozlowski <hidden> Date: 2022-02-10 08:34:51
The PREEMPT_RT patchset does not use soft IRQs thus trying to filter for
do_softirq fails for such kernel:
echo do_softirq
ftracetest: 81: echo: echo: I/O error
Choose some other visible function for the test.
Signed-off-by: Krzysztof Kozlowski <redacted>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
---
Changes since v1:
1. Use scheduler_tick.
2. Add review tag.
Notes:
I understand that the failure does not exist on mainline kernel (only
with PREEMPT_RT patchset) but the change does not harm it.
If it is not suitable alone, please consider it for RT patchset.
---
.../selftests/ftrace/test.d/ftrace/func_set_ftrace_file.tc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Krzysztof Kozlowski <hidden> Date: 2022-02-10 14:05:33
On 10/02/2022 14:47, Sebastian Andrzej Siewior wrote:
On 2022-02-10 09:33:56 [+0100], Krzysztof Kozlowski wrote:
quoted
The PREEMPT_RT patchset does not use soft IRQs thus trying to filter for
do_softirq fails for such kernel:
PREEMPT_RT does use soft IRQs.
Correct. It does not use do_softirq() code, but follows different path
with ksoftirqd.
Shall I rephrase it towards something like this? Or maybe you have some
more accurate description?
The implementation detail is that do_softirq() is in ifndef.
quoted
echo do_softirq
ftracetest: 81: echo: echo: I/O error
Choose some other visible function for the test.
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2022-02-10 14:10:50
On 2022-02-10 15:05:24 [+0100], Krzysztof Kozlowski wrote:
On 10/02/2022 14:47, Sebastian Andrzej Siewior wrote:
quoted
On 2022-02-10 09:33:56 [+0100], Krzysztof Kozlowski wrote:
quoted
The PREEMPT_RT patchset does not use soft IRQs thus trying to filter for
do_softirq fails for such kernel:
PREEMPT_RT does use soft IRQs.
Correct. It does not use do_softirq() code, but follows different path
with ksoftirqd.
Shall I rephrase it towards something like this? Or maybe you have some
more accurate description?
It would be good to describe what the purpose of the change in terms of
the actual problem and the aimed solution.
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.
From: Krzysztof Kozlowski <hidden> Date: 2022-02-10 14:13:22
On 10/02/2022 15:10, Sebastian Andrzej Siewior wrote:
On 2022-02-10 15:05:24 [+0100], Krzysztof Kozlowski wrote:
quoted
On 10/02/2022 14:47, Sebastian Andrzej Siewior wrote:
quoted
On 2022-02-10 09:33:56 [+0100], Krzysztof Kozlowski wrote:
quoted
The PREEMPT_RT patchset does not use soft IRQs thus trying to filter for
do_softirq fails for such kernel:
PREEMPT_RT does use soft IRQs.
Correct. It does not use do_softirq() code, but follows different path
with ksoftirqd.
Shall I rephrase it towards something like this? Or maybe you have some
more accurate description?
It would be good to describe what the purpose of the change in terms of
the actual problem and the aimed solution.
The purpose was explain - fix a failing test with PREEMPT_RT. I am not
planning to rework entire test, it is merely a fix.
quoted
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?
Best regards,
Krzysztof
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2022-02-10 14:48:47
On 2022-02-10 15:13:15 [+0100], Krzysztof Kozlowski wrote:
On 10/02/2022 15:10, Sebastian Andrzej Siewior wrote:
The purpose was explain - fix a failing test with PREEMPT_RT. I am not
planning to rework entire test, it is merely a fix.
What I got confused by is the fact that you do
s/do_softirq/scheduler_tick/ without any explanation why that is correct.
After looking into the test it appears that two random functions are
enough to be specified because the actual purpose is it to figure out if
the function is recorded and not the actual functionality behind the
function.
quoted
quoted
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?
I questioned the purpose of FUNC2 in this context so I don't have to
look into the actual test. But I did, see above ;)
From: Steven Rostedt <rostedt@goodmis.org> Date: 2022-02-10 15:08:02
On Thu, 10 Feb 2022 15:48:41 +0100
Sebastian Andrzej Siewior [off-list ref] wrote:
After looking into the test it appears that two random functions are
enough to be specified because the actual purpose is it to figure out if
the function is recorded and not the actual functionality behind the
function.
Correct. And if I ever do get a chance to revisit this test, I plan on
adding a bunch of comments to it. It's hard enough to add tests for one's
code, but even harder to document what those tests actually do ;-)
-- Steve
From: Steven Rostedt <rostedt@goodmis.org> Date: 2022-02-10 15:05:48
On Thu, 10 Feb 2022 15:13:15 +0100
Krzysztof Kozlowski [off-list ref] wrote:
quoted
quoted
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