Re: [PATCH] ARM: sched_clock: Add more notrace to prevent recursion

From: Stephen Boyd
Date: Tue Mar 26 2013 - 13:35:55 EST


On 03/21/13 10:49, Stephen Boyd wrote:
> On 03/14/13 17:08, Stephen Boyd wrote:
>> cyc_to_sched_clock() is called by sched_clock() and cyc_to_ns()
>> is called by cyc_to_sched_clock(). I suspect that some compilers
>> inline both of these functions into sched_clock() and so we've
>> been getting away without having a notrace marking. It seems that
>> my compiler isn't inlining cyc_to_sched_clock() though, so I'm
>> hitting a recursion bug when I enable the function graph tracer,
>> causing my system to crash. Marking these functions notrace fixes
>> it. Technically cyc_to_ns() doesn't need the notrace because it's
>> already marked inline, but let's just add it so that if we ever
>> remove inline from that function it doesn't blow up.
> Anyone else seeing this problem?

Russell, should I put this into the patch tracker?

>> Signed-off-by: Stephen Boyd <sboyd@xxxxxxxxxxxxxx>
>> ---
>> arch/arm/kernel/sched_clock.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
>> index bd6f56b..59d2adb 100644
>> --- a/arch/arm/kernel/sched_clock.c
>> +++ b/arch/arm/kernel/sched_clock.c
>> @@ -45,12 +45,12 @@ static u32 notrace jiffy_sched_clock_read(void)
>>
>> static u32 __read_mostly (*read_sched_clock)(void) = jiffy_sched_clock_read;
>>
>> -static inline u64 cyc_to_ns(u64 cyc, u32 mult, u32 shift)
>> +static inline u64 notrace cyc_to_ns(u64 cyc, u32 mult, u32 shift)
>> {
>> return (cyc * mult) >> shift;
>> }
>>
>> -static unsigned long long cyc_to_sched_clock(u32 cyc, u32 mask)
>> +static unsigned long long notrace cyc_to_sched_clock(u32 cyc, u32 mask)
>> {
>> u64 epoch_ns;
>> u32 epoch_cyc;


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/