New Daily Builds: Thread Safety

Jeffrey Altman <[email protected]>
Newsgroups gmane.comp.file-systems.openafs.devel.win32
Organization Mass
Message-ID <[email protected]>
Hi folks:

Ever since I started working on OpenAFS for Windows last November
I have been struggling with thread safety and resource management
issues.  The vast majority of the problems were solved sometime
around AFS Best Practice's conference in March.  However, there
were still one set of linger problems which I could not track down.
When "fs crypt" was set, afsd_service.exe would frequently crash
in the afsrpc (rx) library.  This was most apparent on hyperthreaded
Intel processors.

AFS file servers on unix began to experience similar problems on
an ever more frequent basis over the last couple of months.  The
resulted in a concerted effort to track down the cause of the problem.
Once again the problem turned out to be a a failure to properly
reference count objects which are in use.  This failure led to the
destruction of objects representing the RPC connections while they
were in use.  At this point a crash might occur.  Another side effect
was that udp socket handles were leaking within the kernel.

The reason these problems were so common on Windows turned out to be
another bug.  The Windows code was comparing apples and oranges
when verifying that the "fs crypt" value of the RPC connection
matched the current setting.  The comparison always failed and
the RPC connection was destroyed and replaced.  This was an serious
waste of resources.

With the latest daily builds the handle count of afsd_service.exe
stays in the low hundreds and does not grow without bounds even on
multiprocessor machines.  In addition, there are no more crashes.
Write performance is improved although read performance appears to
be slightly impacted by the work necessary to maintain proper reference
counts.

Overall I am quite excited by the fact that this problem is finally
resolved.  Please test these builds on your systems.  We will probably
release a 1.3.72 build fairly soon.

I have uploaded new daily builds to their usual location:

   /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/
   \\afs\athena.mit.edu\user\j\a\jaltman\Public\OpenAFS\
   http://web.mit.edu/~jaltman/Public/OpenAFS/

The list of changes since 1.3.71 include:

   * fix the Windows cache manager to prevent it from replacing the
     rx_connection object associated with the cm_conn_t object on each
     and every operation if "fs crypt" was set.  This explains the
     dramatic performance difference when crypt is used vs clear.
     The problem: 'cryptall', a boolean flag indicating whether or not
     "fs crypt" is set, was being compared to the rx_connection
     cryptlevel which is either rxkad_clear:0 or rxkad_crypt:2.
     1 != 2 and therefore the rx_connection was always destroyed
     and replaced on each and every operation.

     Lock the cm_conn_t object around every call to RXAFS_xxxx functions.
     It is not safe for the cm_conn_t object to not be locked because
     rx_DestroyConnection might be called from another thread if:
         - the user's tokens have changed or expired
         - the crypt mode has changed

   * fix NSIS installer's AdminGroup.exe to properly create and
     remove groups when given -create or -remove.  The string comparison
     test was wrong.

   * fs sysname now accepts a list of sysname values

   * added a new registry value HKLM\SOFTWARE\OpenAFS\Client "IoctlDebug"
     DWORD which when set to a non-zero value will cause error message
     text to be output to stderr from the pioctl() routine.  Useful in
     debugging failures of fs.exe, tokens.exe, etc.

   * added a test to the power management code to only perform a
     flush operation if there is at least one network adapter which
     is not a loopback adapter.

   * Fix bug in loading of registry value HKLM\SOFTWARE\OpenAFS\Client
     "EnableKFW".  This value will not be read if the key
     HKCU\SOFTWARE\OpenAFS\Client exists; even if the "EnableKFW"
     value under that key does not.

   * provide mechanisms to force the use of krb524d for Kerberos 5
     ticket to AFS token conversion.  For afslogon.dll and afscreds.exe
     there is a new registry value "Use524" and for aklog.exe a new
     command line parameter "-m".

   * Fix the pattern matching algorithm to properly match patterns
     ending with a '*'.

   * smb_ReceiveCoreRename() was factored to produce smb_Rename()
     which is used by both the original function and the new
     smb_ReceiveNTRename().  smb_ReceiveNTRename() supports the
     creation of HardLinks in addition to Renaming.  smb_Link()
     is a new function which creates HardLinks via cm_Link().
     cm_Link() is a new vnodeops function which creates links
     using RXAFS_Link().

     smb_ReceiveNTRename() does not support the File Copy and
     Move Cluster Information operations described in its interface.
     ReceiveNTRename is under documented in CIFS-TR-1p00_FINAL.pdf.

   * When opening files via symlinks, we should follow the symlinks
     until we reach the actual file stat cache entry.  The stat cache
     entry of the file should then be stored in the FID instead of
     stat scache entry of the symlink.

   * return bad operation errors for all unimplemented functions
     even if we do not know the functions exist.

   * Log bad packets and unknown operation packets to the trace log

   * Map CM_ERROR_BADOP to STATUS_NOT_SUPPORTED instead of
     0xC09820FF

   * Update list of known CIFS operations to include all those listed
     in CIFS-TR-1p00_FINAL.pdf.

   * Modify the handling of HKLM\SOFTWARE\OpenAFS\Client\Submounts
     to support the REG_EXPAND_SZ type.

As always, I encourage all organizations that wish to contribute to 
OpenAFS for Windows development to contact me. Financial contributions 
as well as in kind assistance are seriously appreciated.

Jeffrey Altman
smime.p7s (application/x-pkcs7-signature, 3.2 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.