[linux-cifs-client] cifs krb5/dfs status

[Steven French]

2.6.14 kernel is nearing shutdown, so I decided to defer most of the 25+
pending cifs changesets in the current cifs git tree (with the exception of
the suspend fix from Pavel at SuSE) to 2.6.15.  From the Samba people's
perspective the most interesting changes in the development tree (in -mm
but not in mainline until next week or so) are the Windows ME/9x
enablement.  The next big set of changes going in the development tree will
be the writepages patch.   It provides a huge performance boost in large
file copy to a reasonable speed server and is important (I wish we
understood why the performance to Samba craters with writes over about 40K,
probably some tcp issue).     Next up is the upcall mechanism which I want
to merge ASAP as soon as 2.6.14 closes down (in about one week) and 2.6.15
opens - because most of the upcall alternatives used by current modules are
terrible and I want to give people a chance to throw stones at it.

I have the item for adding krb5 support as my work priority to complete by
early December, which I think is doable.   I am targetting 2.6.15 or 2.6.16
kernel for experimental version of krb5/spnego enablement for cifs (upcall
to ntlm_auth to build the spnego blob) to be in mainline (probably cifs
version 1.39 or so).   DFS may turn out to be easier and doable by 2.6.16
(or earlier), albeit slightly lower priority, but there is some risk due to
the potential for deadlock which occurs from calling kernel sys_mount
(implicitly) with the parent directory's inode semaphore already held by
lookup (when the directory turns out to be a dfs junction).   These dates
could accelerate with more external patches on these topics, but I am
expecting lots of bug activity as people try cifs to Windows 9x, ME and
then when I add negprot for lanman1.2 string, I expect to see bug reports
coming in on mounts to those servers as people try the new support out - so
I am hesitant to pin down a date for dfs support.    The remaining items
needed (in lines of code) for DFS support would be quite small (as much of
the code is already complete and long merged).   My guess is that the least
understood item of the critical krb5 items is whether cifs packet signing
for krb5 sessions will take much work.



Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
-------------- next part --------------
HTML attachment scrubbed and removed