RE: Embedded C code - functions that might sleep

["Turgis, Frederic" <f-turgis at ti dot com>]

Thanks for the explanation and thread is giving good light on this.

My point is that systemtap design and doc seem to imply I can't call some functions in embedded C because of relevant systemtap design choices. In our script, we are in fact users, not developers of this called function. My goal is to know if there is no easy trick or "specific" mode of systemtap not mentioned in doc where I could still call them or if these functions (like opening OMAP GP timer) are definitely forbidden. Or if this is bad using them, but this is just profiling script on a dev mobile phone so who cares about hanging from time to time ? ;-)

Eventually, we would need to rewrite the function or mimic its functionality in embedded C, respecting the specific constraints. This can be far more work based on our expertise/time requirements so we need to check benefits.


Regards
Fred

Frederic Turgis

OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement - System Multimedia



Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----
From: Mark Wielaard [mailto:mjw@redhat.com]
Sent: Wednesday, February 01, 2012 2:34 PM
To: Turgis, Frederic
Cc: systemtap@sourceware.org
Subject: Re: Embedded C code - functions that might sleep

Hi Frederic,

On Wed, 2012-02-01 at 12:27 +0000, Turgis, Frederic wrote:
> systemtap doc states: "Note that all SystemTap functions and probes run with interrupts disabled, thus you cannot call functions that might sleep within the embedded C."
>
> This would explain issues we get with below probe on ARM platform (OMAP):
> - open a GP timer through function that calls mutex_lock() in "begin" probe -> it gives "BUG: sleeping function called from invalid context".

In general probes can occur anywhere, so might be triggered in interrupt context. You would see the above message also if you are holding any locks (sleeping while holding locks is bad, since there is no guarantee the lock will ever be released again). If you are running a kernel with lockdep enabled it should tell you exactly why it is yelling at you.
(Note that only very recently, like 30 minutes ago, we fixed some lockdep issue with user probes, see the thread on the mailinglist).

Cheers,

Mark