[PATCH 3.19-rc2 v14 0/7] arm: Implement arch_trigger_all_cpu_backtrace
Daniel Thompson
daniel.thompson at linaro.org
Thu Jan 22 03:21:51 PST 2015
On 21/01/15 13:48, Daniel Thompson wrote:
> On 21/01/15 13:06, Steven Rostedt wrote:
>> On Wed, 21 Jan 2015 10:47:37 +0000
>> Daniel Thompson <daniel.thompson at linaro.org> wrote:
>>
>>
>>>> With this patchset, is it possible to call sched_clock() from within NMI
>>>> context? I ask because the generic sched_clock() code is not NMI safe
>>
>> That's not good. Better not run function tracing, as that could trace
>> functions in NMI context (I depend on that it does), and it uses
>> sched_clock() as the default clock.
>
> I think sched_clock is unsafe as in "may sometimes give the wrong value"
> rather than "can lock up arbitrarily". Thus the impact is unlikely to
> be harmful enough to want to avoid tracing altogether.
Just to update the record...
The above paragraph is wrong in every possible way. It is a livelock
(and I'm working on it).
> It would require special care be taken when interpreting the timestamps
> however. Also since update_sched_clock() is a notrace function its very
> hard to figure out when timestamps are at risk.
>
> Anyhow, the fix doesn't seem that hard. I can take a look.
>
>
> Daniel.
>
More information about the linux-arm-kernel
mailing list