[PATCH] ARM: ensure all sched_clock() implementations are notrace marked

Rabin Vincent rabin at rab.in
Thu Dec 16 11:22:56 EST 2010


On Thu, Dec 16, 2010 at 9:27 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Thu, Dec 16, 2010 at 08:42:23PM +0530, Rabin Vincent wrote:
>> On Thu, Dec 16, 2010 at 1:48 PM, Russell King - ARM Linux
>> <linux at arm.linux.org.uk> wrote:
>> > ftrace requires sched_clock() to be notrace.  Ensure that all
>> > implementations are so marked.
>> >
>> > Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
>>
>> It does seem better to have all of them explicity annotated anyway, even
>> if it not required in most of the cases because they include
>> <linux/sched.h> and the annotation in the declaration takes effect.
>
> Firstly, we shouldn't be relying upon that, and secondly, everywhere which
> defines sched_clock() should already be including linux/sched.h to avoid
> the sparse error.  It sounds like there's also an exercise to make sure
> that is the case.

Yes.  I believe I identified all the ones which weren't including the
header in the last notrace series I sent out (versatile, plat-iop, omap,
and u300 IIRC), but there's been some changes in various platforms'
sched_clocks() and of course new platforms since then.

>
>> Note that in order for this to be fully effective, all functions called
>> from sched_clock() need to be notrace too.  OMAP and u300 miss this.
>
> Yes, OMAP still suffers from this.
>
> However, I assume you haven't looked at the u300 sched_clock conversion
> patch which is part of a follow-on series on lakml?  It sorts u300 out
> in that regard.

Yes, I now see U300 no longer needs the notrace addition.  It still
could do with the #include <linux/sched.h> addition though, which was
also being done as part of that patch.



More information about the linux-arm-kernel mailing list