On 03/26/13 10:35, Stephen Boyd wrote:
> 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?
I'll throw this into the patch tracker tomorrow if nobody complains.
>>> 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-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
