[linux-cifs-client] RE: linux-cifs-client Digest, Vol 63, Issue 2

Werner Maes Werner.Maes at icts.kuleuven.be
Tue Feb 3 15:55:50 GMT 2009


> >
> > Igor,
> >
> > I would love to work on this bug but I do not know how to recreate
> it.
> > I can't mount a share using domain name in the UNC like Werner does.


is your domain resolvable through DNS?
 
> Actually there where to problems on this thread.
> 
> 1. Mounting remote dfs root.
>    1.1 The server that responds PATH_UNCOVERED on mount attempt.
>        Mount returns with -EREMOTE. Often happens when attempting mount
>        by domain name.
>    1.2 Mounting with remote prefixpath. In this case tree connect is
> successful,
>        but root inode lookup lead us to cifs_dfs_follow_mountpoint and
> assert
>        "kernel BUG at fs/cifs/cifs_dfs_ref.c:274!".
>        If you comment out this line then you'll be able to mount/use
> share but
>        won't be able to unmount it anymore.
> 
> Problem 1 is almost solved, I just need some time to cleanup patches
> I've written.
> 
> 
> 2. Server returns referrals without any server holding storage.
>    Todays implementation is a list scan in
>    cifs_dfs_follow_mountpoint starting at cifs_dfs_ref.c:346
>    attempting to mount any referral that has flag
> DFSREF_STORAGE_SERVER.
> 
>    Server may respond with referrals without flag DFSREF_STORAGE_SERVER
> set.
>    That just tells us that a server in a referral may know the storage
> server name
>    and we shall ask it for referrals instead of attempting to mount.
>    Example:
>        SRV1 returns 2 referrals SRV2 and SRV5 without
> DFSREF_STORAGE_SERVER flag set.
>        Client should go down the tree and ask each server till it get
> referral with
>        DFSREF_STORAGE_SERVER flag set.
> 
>                SRV1
> 	      /   \
>            SRV2   SRV5
>            /         \
>         SRV3        SRV4
>                        \
>                     STORAGE
> 
> 
>    So essentially we need to implement a tree walk with a detection of
>    possible loops in case of misconfiguration to avoid infinite loop in
> kernel.
> 
yes, that seems to be what we need ! 

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm



More information about the linux-cifs-client mailing list