Re: concept prove patch for ktrace output to all file types

On Fri, 29 Jun 2007, Howard Su wrote:

> On 6/28/07, Robert Watson <rwatson_at_freebsd.org> wrote:
>> 
>> What happens to processes associated with the same or other ktrace sessions 
>> if one ktrace session stalls due to a fifo or pipe buffer filling?
>
> I don't think my patch will bring the new problem here. Original, we write 
> to disk still be blocked due to some things like disk busy, etc.
>
> If my reading is right, ktrace use two way to submit request. ktr_enqueue 
> will put the request into a queue if it is not safe to enter VFS. 
> ktr_submitrequest will be used to commit record to disk immediately. in my 
> case, blocking will be safe there.
>
> The issue about losting some recording to fifo blocking. I don't think we 
> can solve that in the kernel. It is userland code's responsiblity to read it 
> to avoid losting data.

The question I'm asking is most interesting with respect to independent ktrace 
sessions, potentially associated with different users.  If a tracing app can't 
keep up with the app it's tracing, that's quite a different case from all 
system tracing breaking because one tracing app can't keep up with its 
particular target.  In a casual analysis, it looks like if one fifo blocks, 
then all tracing across the system is stuck waiting on that fifo to unblock?

Robert N M Watson
Computer Laboratory
University of Cambridge