[linux-cifs-client] DFS support in CIFS

[Q]

Steve French wrote:
> Q wrote:
>> Steve French wrote:
>>>> Currently I'm writing DFS support in cifs kernel module
>>>> At current state I can work read/write/list files in DFS shares and 
>>>> so on.
>>>> Only two big things hasn't been done:
>>>
>>> 2. not enough knowledge to do propper cleanup when cleaning nested 
>>> trees, module crashes on 'rmmod cifs'
>>>
>>> So, Does anybody know a way to accomplish 1 problem or any proposal how
>>>
>>> I had finished part of the code necessary for DFS a few years ago 
>>> (and they are in mainline) as you have probably noticed.
>>>
>>> CIFS code can recognize DFS referral, get the referral list - and for 
>>> referrals with server as ip address could probably work today with 
>>> small changes.  ip address based referrals are ok, although not common.
>>
>> Yes, What I've done is based on your code, just a little rewriting, 
>> fixing, copypasting :) and DFS works.
>>
>>>
>>>> 1. resolving server names to ip in kernel space
>>> I think the easiest approach for kernels 2.6.12 or later will be to 
>>> define a key type (keyed on hostname) for the upcall and use the
>>> key management api to return the ip address (see 
>>> Documentation/keys.txt etc and Dave Howells web page at RedHat).  
>>> Most other
>>> upcall possibilities (captive ioctl, cn.ko, or worse netlink, or 
>>> pseudo-fs require a long running daemon which is probably not ideal, 
>>> and also have some problems with reliability).  This should probably 
>>> not be a cifs specific key type
>>> but cifs would be the first user of it.
>>
>> Ok. I've done it using keys API.
>>
>>
>>>> 2. not enough knowledge to do propper cleanup when cleaning nested 
>>>> trees, module crashes on 'rmmod cifs'
>>> There may be a way to do this with explicit mounts from a daemon in 
>>> userspace (I hope we can avoid this) but surely this
>>> is something the automounter deals with.  Again the key request api 
>>> (with a null, noncached key - passing as description
>>> the mount parms you want to issue?) might work.  An alternative if 
>>> mount in kernel could be to attached a list of the
>>> "sub-mounts" (implicit dfs mounts) off the CIFS_SB (cifs specific 
>>> portion of the superblock).
>>>
>>> In any case - let's discuss this more.  I would like to take a look 
>>> at integrating this - the DFS code has languished too long.
>>
>> At first I tried to use implicit mounts from kernel space, but it 
>> appeared to be a hell for me so I've moved to another direction.
>>
>> Here is short description of what I've done.
>>
>> 1. Added alternate altpTcon field to inode so that
>>    if path is remote we connect to dfs link and assign new tcon
>>    to altpTcon in new inode.
>>
>> 2. Rewrote almost all usage of pTcon from superblock to use altpTcon 
>> if it's available. (except of links.c maybe)
>>
>> 3. Added server name resolving using keys API
>>
>> 4. Added possibility to mount to subtree in share even it is DFS link.
>> i.e. \\\\servername\sharename\my\subtree\root
>>
>> For that I've added UNCsubtree field to smb_vol and moved it to 
>> cifs_sb_info. Now if there is UNCsubtree then it is added to full path 
>> name before sending request to server.
>>
>> 5. Replaced global cifsd_complete to srv_cifsd_complete for each server
>>    to remove race condition when closing nested connections.
>>
>> That's all, maybe.
>> It's quite stable while you do not umount dfs root and don't rmmod cifs.
>> Today it even not crashed after umount and rmmod, maybe because of I 
>> lunched netdump to catch BUGS that I've written and now they are 
>> hiding from me :)
>>
>> Here is patch made  against 1.45 version from 
>> http://us1.samba.org/samba/ftp/cifs-cvs/cifs-1.45.tar.gz
>>
>>
> Seems like there are too many ideas in one patch, and the indentation 
> changes in cifspdu.h make it harder to find your important changes and 
> also violate kernel style rules, although I am looser with those than 
> some (kernel structs in headers usually start on column one, you moved 
> them one tab in)

Yes, I've need it in working condition as soon as possible so I didn't 
pay much attention to formating and kernel style rules. I'll try read 
something about kernel style rules before doing changes to kernel code.

> Some of your changes did remind me of other things though, e.g. what 
> about kthread API on cifsd threads instead of trying to change the 
> completion code?

Well, change in completion code fixes race anyway, but I'll look at 
kthread API later (may be in a month).

-- 

Best regards,

-------------------------
Igor Mammedov,
niallain "at" gmail.com