[linux-cifs-client] [PATCH] cifs: guard against hardlinking directories

[Suresh Jayaraman]

On 05/07/2010 07:33 PM, Jeff Layton wrote:
> When we made serverino the default, we trusted that the field sent by the
> server in the "uniqueid" field was actually unique. It turns out that it
> isn't reliably so.
> 
> Samba, in particular, will just put the st_ino in the uniqueid field when
> unix extensions are enabled. When a share spans multiple filesystems, it's
> quite possible that there will be collisions. This is a server bug, but
> when the inodes in question are a directory (as is often the case) and
> there is a collision with the root inode of the mount, the result is a
> kernel panic on umount.
> 
> Fix this by checking explicitly for directory inodes with the same
> uniqueid. If that is the case, then we can assume that using server inode
> numbers will be a problem and that they should be disabled.
> 
> Signed-off-by: Jeff Layton <jlayton at redhat.com>
> ---
>  fs/cifs/cifsglob.h |    1 +
>  fs/cifs/inode.c    |   21 +++++++++++++++++++--
>  2 files changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
> index ecf0ffb..0c2fd17 100644
> --- a/fs/cifs/cifsglob.h
> +++ b/fs/cifs/cifsglob.h
> @@ -502,6 +502,7 @@ struct dfs_info3_param {
>  #define CIFS_FATTR_DFS_REFERRAL		0x1
>  #define CIFS_FATTR_DELETE_PENDING	0x2
>  #define CIFS_FATTR_NEED_REVAL		0x4
> +#define CIFS_FATTR_INO_COLLISION	0x8
>  

Nice and thoughful solution! I was not for disabling serverino as a default.

I have a nice way of reliably reproducing the problem.

- create two small partitions and format (ext3)
- mount first partition as /vol1 and mount the second as /vol1/vol2
  inside the first
- create files on both partitions (say 10 files)
- export them
- mount from the client, access them
- the inode numbers will easily collide
- umount them and the client will crash..

I'm trying out the fix and will be able to verify (hopefully before I
catch my train in another couple of hours). Will revert back after testing.


Thanks,



-- 
Suresh Jayaraman