This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Embedded C code - functions that might sleep


Hi,

Well, "little badness" could be fun !

Within the team, I got interesting question if interrupt disabling could be relaxed for begin/end probes (through compilation flag), which would be executed in safer contexts as not being kprobes. That would be sufficient for our needs.
In the code, I see that begin probe is called when module receives STP_START command and end probe on STP_EXIT or module unload.

Still "enter_be_probe()" in generated code relies on preempt_disable()/enable() or local_irq_save()/restore(). Is there some other constraint to take into account ?

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 5:07 PM
To: Turgis, Frederic
Cc: systemtap@sourceware.org
Subject: RE: Embedded C code - functions that might sleep

On Wed, 2012-02-01 at 14:47 +0000, Turgis, Frederic wrote:
> 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 ? ;-)

I am afraid that in general you just cannot sleep in a probe handler. If you still try "bad things" might happen. Like hanging or even crashing.
In some cases there are variants that also work in atomic context (for example you can do some allocations with GFP_ATOMIC) but I don't know if the OMAP GP timer provides such functionality/mode.

That said, if you are using guru mode already you are kind of on your own anyway. In a lot of cases you might just get away with a little badness. Just hope the function doesn't really sleep or schedule the current task away...

Cheers,

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]