Date: Fri, 07 Jun 2002 12:35:31 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: arch@FreeBSD.org Subject: KTRACE genio trace question Message-ID: <XFMail.20020607123531.jhb@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020607123531.jhb>