All of lore.kernel.org
 help / color / mirror / Atom feed
From: Quanyang Wang <quanyang.wang@windriver.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Leo Yan <leo.yan@linaro.org>, Will Deacon <will@kernel.org>,
	a.darwish@linutronix.de,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Paul Cercueil <paul@crapouillou.net>,
	Randy Dunlap <rdunlap@infradead.org>,
	ben.dooks@codethink.co.uk, Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH] time/sched_clock: mark sched_clock_read_begin as notrace
Date: Mon, 28 Sep 2020 20:41:59 +0800	[thread overview]
Message-ID: <22a5d255-7a9f-3139-1e8a-4263fea690c0@windriver.com> (raw)
In-Reply-To: <20200928105859.GF2628@hirez.programming.kicks-ass.net>

Hi Peter,

On 9/28/20 6:58 PM, Peter Zijlstra wrote:
> On Mon, Sep 28, 2020 at 06:49:52PM +0800, quanyang.wang@windriver.com wrote:
>> From: Quanyang Wang <quanyang.wang@windriver.com>
>>
>> Since sched_clock_read_begin is called by notrace function sched_clock,
>> it shouldn't be traceable either, or else __ftrace_graph_caller will
>> run into a dead loop on the path (arm for instance):
>>
>>    ftrace_graph_caller
>>      prepare_ftrace_return
>>        function_graph_enter
>>          ftrace_push_return_trace
>>            trace_clock_local
>>              sched_clock
>>                sched_clock_read_begin
>>
>> Fixes: 1b86abc1c645 ("sched_clock: Expose struct clock_read_data")
>> Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>
>> ---
>>   kernel/time/sched_clock.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
>> index 1c03eec6ca9b..58459e1359d7 100644
>> --- a/kernel/time/sched_clock.c
>> +++ b/kernel/time/sched_clock.c
>> @@ -68,7 +68,7 @@ static inline u64 notrace cyc_to_ns(u64 cyc, u32 mult, u32 shift)
>>   	return (cyc * mult) >> shift;
>>   }
>>   
>> -struct clock_read_data *sched_clock_read_begin(unsigned int *seq)
>> +notrace struct clock_read_data *sched_clock_read_begin(unsigned int *seq)
>>   {
>>   	*seq = raw_read_seqcount_latch(&cd.seq);
>>   	return cd.read_data + (*seq & 1);
> At the very least sched_clock_read_retry() should also be marked such.

In fact, the sched_clock_read_retry is treated as a "inline" function, so

it doesn't trigger the  dead loop. But for safe, add notrace to it is 
better.

I will send a V2 patch.

Thanks,

Quanyang


>
> But Steve, how come x86 works? Our sched_clock() doesn't have notrace on
> at all.

  reply	other threads:[~2020-09-28 12:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-28 10:49 [PATCH] time/sched_clock: mark sched_clock_read_begin as notrace quanyang.wang
2020-09-28 10:58 ` Peter Zijlstra
2020-09-28 12:41   ` Quanyang Wang [this message]
2020-09-28 21:33   ` Steven Rostedt
2020-09-29  7:13     ` Peter Zijlstra
2020-09-29 14:43       ` Steven Rostedt

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=22a5d255-7a9f-3139-1e8a-4263fea690c0@windriver.com \
    --to=quanyang.wang@windriver.com \
    --cc=a.darwish@linutronix.de \
    --cc=ben.dooks@codethink.co.uk \
    --cc=daniel.lezcano@linaro.org \
    --cc=leo.yan@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@crapouillou.net \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.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.