|
|
|
|
|
|
| Author |
Message |
John Baldwin
*nix forums Guru Wannabe
Joined: 27 Mar 2002
Posts: 278
|
 Posted: Fri Jun 07, 2002 7:34 pm Post subject:
Re: KTRACE genio trace question
|
|
|
On 07-Jun-2002 Terry Lambert wrote:
| Quote: | 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()).
| Quote: | 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 |
|
| Back to top |
|
 |
Alfred Perlstein
*nix forums addict
Joined: 19 Mar 2002
Posts: 67
|
| Posted: Fri Jun 07, 2002 4:35 pm Post subject:
Re: KTRACE genio trace question
|
|
|
* John Baldwin <jhb@FreeBSD.org> [020607 09:35] wrote:
| Quote: |
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?
|
That sounds reasonable.
-Alfred
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Fri Jun 07, 2002 4:35 pm Post subject:
Re: KTRACE genio trace question
|
|
|
John Baldwin wrote:
| Quote: | 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?
| Quote: | 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?
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
John Baldwin
*nix forums Guru Wannabe
Joined: 27 Mar 2002
Posts: 278
|
| Posted: Fri Jun 07, 2002 4:35 pm Post subject:
KTRACE genio trace question
|
|
|
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 |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Thu Jan 08, 2009 5:58 am | All times are GMT
|
|
Debt Consolidation | Debt Consolidation | Debt Consolidation | Loans | Western Union Money Order
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
