Re: [PATCH] cifs: guard against hardlinking directories
Suresh Jayaraman <[email protected]> Fri, 07 May 2010 20:38:52 +0530
| Newsgroups | gmane.linux.file-systems.cifs |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> > --- > 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