From owner-freebsd-arch Fri Jun 7 9:35:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by hub.freebsd.org (Postfix) with ESMTP id 5ABE837B404 for ; Fri, 7 Jun 2002 09:35:40 -0700 (PDT) Received: (qmail 544 invoked from network); 7 Jun 2002 16:35:39 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 7 Jun 2002 16:35:39 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g57GZbF65998 for ; Fri, 7 Jun 2002 12:35:38 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 07 Jun 2002 12:35:31 -0400 (EDT) From: John Baldwin To: arch@FreeBSD.org Subject: KTRACE genio trace question Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'd like to get some feedback on proposing a change to the ktrace behavior for I/O trace events. Currently for an I/O trace, we store all of the contents of the I/O to the trace file. We used to do this by malloc'ing a buffer tha we copyin'd all the data to that was then written out along with the ktrace header in one VOP_WRITE. green changed this in revision 1.37 of kern_ktrace.c to instead use a copy of the original uio and split the write operation into two VOP_WRITE's. However, this can result in a corrupt tracefile if the first VOP_WRITE succeeds but the second one fails. Also, since we defer the copyin() until the VOP_WRITE, the actual VOP_WRITE needs to be done by the original thread requiring ugly synchronization between the ktrace worker thread and the thread submitting a trace request. The reason for green's change was to prevent DoS attacks from users doing a ktrace of a program doing very large I/O operations. I would like to avoid the DoS while rectifying the problems mentioned above. What I would like to do is change the behavior of I/O trace events to go back to doing the copyin() before the VOP_WRITE(), but to set a max limit on the amount of data we will output in the trace. This limit would probably default to a single page and could be a loader tunable and sysctl. This would allow us to get rid of the need for synchronous ktrace events cleaning up the ktrace code a bit. It would also go back to using a single VOP_WRITE for all of the the I/O. Thoughts? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message