Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6

Pull cifs updates from Steve French:
 "Various CIFS/SMB2/SMB3 updates for 3.11.  Includes bug fixes - SMB3
  support should be much more stable with key DFS fix and also signing
  possible now (although is more work to do to get SMB3 signing working
  well with multiuser).

  Mounts using the new SMB 3.02 dialect can now be done (specify
  "vers=3.02" on mount) against the most current Microsoft systems.

  Also includes a big cleanup of the cifs/smb2/smb3 authentication code
  from Jeff which fixes some long standing problems with the way allowed
  authentication flavors and signing are configured.

  Some followon patches later in the cycle will clean up allocation of
  structures for the various security mechanisms depending on what
  dialect is chosen (reduces memory usage a little) and to add support
  for the secure negotiate fsctl (for smb3) which prevents downgrade
  attacks."

* 'for-next' of git://git.samba.org/sfrench/cifs-2.6: (39 commits)
  cifs: fill TRANS2_QUERY_FILE_INFO ByteCount fields
  cifs: fix SMB2 signing enablement in cifs_enable_signing
  [CIFS] Fix build warning
  [CIFS] SMB3 Signing enablement
  [CIFS] Do not set DFS flag on SMB2 open
  [CIFS] fix static checker warning
  cifs: try to handle the MUST SecurityFlags sanely
  When server doesn't provide SecurityBuffer on SMB2Negotiate pick default
  Handle big endianness in NTLM (ntlmv2) authentication
  revalidate directories instiantiated via FIND_* in order to handle DFS referrals
  SMB2 FSCTL and IOCTL worker function
  Charge at least one credit, if server says that it supports multicredit
  Remove typo
  Some missing share flags
  cifs: using strlcpy instead of strncpy
  Update headers to update various SMB3 ioctl definitions
  Update cifs version number
  Add ability to dipslay SMB3 share flags and capabilities for debugging
  Add some missing SMB3 and SMB3.02 flags
  Add SMB3.02 dialect support
  ...

1 files changed, 29 insertions, 0 deletions

diff --git a/fs/cifs/readdir.c b/fs/cifs/readdir.c
index f1213799de1..ab877846939 100644
--- a/fs/cifs/readdir.c
+++ b/fs/cifs/readdir.c
@@ -126,6 +126,22 @@ out:
 	dput(dentry);
 }
 
+/*
+ * Is it possible that this directory might turn out to be a DFS referral
+ * once we go to try and use it?
+ */
+static bool
+cifs_dfs_is_possible(struct cifs_sb_info *cifs_sb)
+{
+#ifdef CONFIG_CIFS_DFS_UPCALL
+	struct cifs_tcon *tcon = cifs_sb_master_tcon(cifs_sb);
+
+	if (tcon->Flags & SMB_SHARE_IS_IN_DFS)
+		return true;
+#endif
+	return false;
+}
+
 static void
 cifs_fill_common_info(struct cifs_fattr *fattr, struct cifs_sb_info *cifs_sb)
 {
@@ -135,6 +151,19 @@ cifs_fill_common_info(struct cifs_fattr *fattr, struct cifs_sb_info *cifs_sb)
 	if (fattr->cf_cifsattrs & ATTR_DIRECTORY) {
 		fattr->cf_mode = S_IFDIR | cifs_sb->mnt_dir_mode;
 		fattr->cf_dtype = DT_DIR;
+		/*
+		 * Windows CIFS servers generally make DFS referrals look
+		 * like directories in FIND_* responses with the reparse
+		 * attribute flag also set (since DFS junctions are
+		 * reparse points). We must revalidate at least these
+		 * directory inodes before trying to use them (if
+		 * they are DFS we will get PATH_NOT_COVERED back
+		 * when queried directly and can then try to connect
+		 * to the DFS target)
+		 */
+		if (cifs_dfs_is_possible(cifs_sb) &&
+		    (fattr->cf_cifsattrs & ATTR_REPARSE))
+			fattr->cf_flags |= CIFS_FATTR_NEED_REVAL;
 	} else {
 		fattr->cf_mode = S_IFREG | cifs_sb->mnt_file_mode;
 		fattr->cf_dtype = DT_REG;