Date: Fri, 30 Jan 1998 17:11:55 -0300 From: daniel_sobral@voga.com.br To: hackers@FreeBSD.ORG Subject: Re: TRUSS Message-ID: <8325659C.006CFFB1.00@papagaio.voga.com.br>
next in thread | raw e-mail | index | archive | help
> truss *may* cause problems, timing wise -- the
> target process is stopped until it is restarted,
> and that may be a problem in your case.
> Without more information, I can't quite say,
> I'm afraid.
Oops. Sorry. I have talked quite a bit about the driver last two weeks, so
I ended up forgetting the context.
This is an encryption card. The test program works like this:
<set up device>
<initialize known string>
<loop on mode (two modes)>
<prepare to encrypt>
<getrusage>
write(known-string)
read(encrypted-string)
<getrusage>
<show statistics>
<prepare to decrypt>
<getrusage>
write(encrypted-string)
read(decrypted-string>
<getrusage>
<show statistics>
<check known-string against decrypted-string>
<close device>
Now, when the device receive a write() call, it moves the data to a buffer,
starts the encryption/decryption through a timeout() call, and returns.
Read() will wait until all data is converted, and then move it back from
the buffer. In the test program, read() will always block, and will be
wakeup()ed by the crypt() process, called by timeout().
So, what does crypt() do? Well, read a byte, write it to the device, read
back from the device, store it, update pointers. It is actually a big
switch() statement (dfa), because it will often have to timeout() itself
again and return, since the device is very slow.
Read() does have some critical regions (race conditions against crypt()),
"solved" through splsoftclock().
Last of all, it happens that the decrypted-string will only differ on one
of the modes (turbo). No matter what mode I test first, it will always be
that mode the one to fail. Which is a strong hint that my code may be, in
fact, buggy. I only asked because I don't know truss, I'm not sure if I can
truss it (okay, bad pun, but you used it first on Dr. Dobbs!).
I see only two possibilities (of the blame being with truss): corruption of
either read() or write() data (extremely unlikely), or screwing up issues
with splsoftclock(). Is it possible that truss screws up with
splsoftclock() and, thus, the race condition get triggered on the turbo
mode? I'll gather _much_ more data on this problem when I get back home,
but, for now, the only data I can gather is more information on truss, from
this list... :-)
Happily, it seems that the author of truss actually subscribes to it, and
it's indeed a very nice person... :-)
Btw, if you're going to cc the message to me (or reply to me and cc to
-hackers), please cc also to dcs@gns.com.br.
--
Daniel C. Sobral (8-DCS)
Daniel_Sobral@voga.com.br
Tagline:
* FreeBSD. Earth.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8325659C.006CFFB1.00>