From mboxrd@z Thu Jan  1 00:00:00 1970
From: mathieu.desnoyers@efficios.com (Mathieu Desnoyers)
Date: Fri, 27 Apr 2012 07:33:21 -0400
Subject: [lttng-dev] lttng enable-channel option for blocking
In-Reply-To: <4F9A4A91.7090102@mentor.com>
References: <4F992213.2090103@mentor.com> <20120426211627.GB1646@Krystal>
	<4F9A4A91.7090102@mentor.com>
Message-ID: <20120427113321.GA6987@Krystal>

* Woegerer, Paul (Paul_Woegerer at mentor.com) wrote:
> On 04/26/2012 11:16 PM, Mathieu Desnoyers wrote:
>> I already thought about permitting this, but we currently don't. The  
>> first thing I must say about this is that I prefer to wait a bit  
>> before we add this feature, and think about its impact thoroughly,  
>> because allowing the tracer to block applications gives a lot of power  
>> to the tracer: e.g., if tracing is stopped due to error conditions, or  
>> disk full, or network traffic slowdown, how do we handle the fact that  
>> this might block progress in all traced applications ?
> Good to know that this is on the agenda.
>
> I agree, it gives a lot of power to the tracer. By messing with channel  
> configurations a user could make a tracing application unusable. But the  
> user already has ways to make applications unusable (by messing with  
> ulimit, for example). There is always enough rope to hang yourself.

A core difference between ulimit and user-space tracing is that ulimit
can only be set within the environment (and access right) of the user
running the application. System-wide tracing sessions can be initiated
by users member of the "tracing" group -- giving them the ability to
potentially DoS an application does not appear to me to be a good
security practice.

Thoughts ?

Thanks,

Mathieu

>> The current modes (discard and overwrite) let the applications continue
>> even if there is too much data being recorded into the trace buffers --
>> this is a "safe" approach.
>>
>> How would you recommend dealing with the possible pitfalls of blocking
>> traced applications ? We would need a mechanism in place to ensure
>> gathering a trace cannot make applications unresponsive.
> I guess in case of "lttng enable-channel --block" a user would have to  
> expect that a call to tracepoint() might block. He has to deal with the  
> fact in his application domain (e.g. implement a watchdog mechanism).  
> Nonetheless it might be a good idea to also provide something like  
> tracepointnb() ( a non-blocking variant of tracepoint() ) in case the  
> user doesn't want to deal with (or simply cannot accept) potential 
> blocking.
>
> --
> Thanks,
> Paul
>
> -- 
> Paul Woegerer | SW Development Engineer
> Mentor Embedded(tm) | Prinz Eugen Stra?e 72/2/4, Vienna, 1040 Austria
> P 43.1.535991320
> Nucleus? | Linux? | Android(tm) | Services | UI | Multi-OS
>
> Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions.
> Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
>

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com