From owner-freebsd-current@FreeBSD.ORG Fri Jun 29 11:00:36 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB31316A468 for ; Fri, 29 Jun 2007 11:00:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id B5AE013C45D for ; Fri, 29 Jun 2007 11:00:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 79A4A4820F; Fri, 29 Jun 2007 07:00:17 -0400 (EDT) Date: Fri, 29 Jun 2007 12:00:17 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Howard Su In-Reply-To: Message-ID: <20070629115820.N50751@fledge.watson.org> References: <20070628094219.W9286@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: concept prove patch for ktrace output to all file types X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2007 11:00:36 -0000 On Fri, 29 Jun 2007, Howard Su wrote: > On 6/28/07, Robert Watson 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