Date: Fri, 07 Jun 2002 15:34:15 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: arch@FreeBSD.org Subject: Re: KTRACE genio trace question Message-ID: <XFMail.20020607153415.jhb@FreeBSD.org> In-Reply-To: <3D00F8F6.D020EB53@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07-Jun-2002 Terry Lambert wrote: > John Baldwin wrote: >> 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. > > Under what circumstances is this possible, such that the original > code would *not* have also failed on the second loop through the > uiomove code? This has very little to do with the uiomove(), but imagine doing ktrace over NFS or some such and having the first write succeed but the second write fail. (Where these are the two VOP_WRITE's in ktr_writerequest()). >> 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. > > I don't understand this requirement; all threads in a thread group > have identical references to the same address spaces. Therefore, > as long as you have the correct process, you shouldn't care, right? The point is it can't be done by the ktrace kernel process which has its own address space. Also, making the original thread do it keeps the original thread from returning and changing the data out from under you. (Aside from any already-existant userland races.) -- 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.20020607153415.jhb>