[OpenAFS] 1.3.6000 integrated logon?

Jeffrey Altman jaltman@columbia.edu
Fri, 19 Mar 2004 09:41:33 -0500


This is a multi-part message in MIME format.
--------------050004040001050208070502
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Stephen Joyce wrote:

>FWIW, I've seen that very slow behavior too, but figured it was something
>I'm doing wrong... (the new versions, .5299 and .6000, also seem to
>consistently crash, with the question about sending a crash report to MS,
>every time I stop the service.)  I see this on WinXPsp1 with only MS
>patches and OpenAFS installed.
>
>

First, the crash is most likely in the new power
management thread.  The thread is not always
shutting down before the service control thread
finishes.  I thought I had that fixed.


As for the slow dialogs I am not sure.  Is there
any additional information you can provide? 

What do you mean by slow?  Delays while entering
text?  Delays from the time the "OK" button is
pressed until the tokens are obtained? 

One point of information is that in OpenAFS I
discovered a very bad race condition between
processes or threads on the same machine within
ktc_SetToken() or ktc_GetToken() calls.  Each
call must perform two steps a pioctl() and an
RPC.  It is possible for two processes making
calls at the same time to be stair stepped
resulting in undesireable results.  Therefore,
I added a global mutex around the pairs of calls
to ensure that only one thread/process is
attempting to perform an operating at a time.
This will introduce a very slight delay because
the Obtain Tokens thread is competing with
another thread within afscreds.exe which is
also performing the pioctl()/RPC call combinations
to obtain token status information.  However,
I cannot imagine the delay is all that great.

Does a network trace reveal anything interesting?

Jeffrey Altman



--------------050004040001050208070502
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Bitstream Cyberbit">Stephen Joyce wrote:<br>
</font>
<blockquote
 cite="midPine.GSO.4.58.0403190841340.9669@titan.physics.unc.edu"
 type="cite">
  <pre wrap=""><font face="Bitstream Cyberbit">FWIW, I've seen that very slow behavior too, but figured it was something
I'm doing wrong... (the new versions, .5299 and .6000, also seem to
consistently crash, with the question about sending a crash report to MS,
every time I stop the service.)  I see this on WinXPsp1 with only MS
patches and OpenAFS installed.

</font></pre>
</blockquote>
<br>
First, the crash is most likely in the new power<br>
management thread.&nbsp; The thread is not always <br>
shutting down before the service control thread<br>
finishes.&nbsp; I thought I had that fixed.<br>
<br>
<br>
As for the slow dialogs I am not sure.&nbsp; Is there<br>
any additional information you can provide?&nbsp; <br>
<br>
What do you mean by slow?&nbsp; Delays while entering<br>
text?&nbsp; Delays from the time the "OK" button is<br>
pressed until the tokens are obtained?&nbsp; <br>
<br>
One point of information is that in OpenAFS I <br>
discovered a very bad race condition between <br>
processes or threads on the same machine within<br>
ktc_SetToken() or ktc_GetToken() calls.&nbsp; Each<br>
call must perform two steps a pioctl() and an<br>
RPC.&nbsp; It is possible for two processes making<br>
calls at the same time to be stair stepped <br>
resulting in undesireable results.&nbsp; Therefore,<br>
I added a global mutex around the pairs of calls<br>
to ensure that only one thread/process is <br>
attempting to perform an operating at a time.<br>
This will introduce a very slight delay because<br>
the Obtain Tokens thread is competing with <br>
another thread within afscreds.exe which is<br>
also performing the pioctl()/RPC call combinations<br>
to obtain token status information.&nbsp; However, <br>
I cannot imagine the delay is all that great.<br>
<br>
Does a network trace reveal anything interesting?<br>
<br>
Jeffrey Altman<br>
<br>
<br>
</body>
</html>

--------------050004040001050208070502--