CIFS: Fix SMB2 readdir error handling commit 52755808d4525f4d5b86d112d36ffc7a46f3fb48 upstream. SMB2 servers indicates the end of a directory search with STATUS_NO_MORE_FILE error code that is not processed now. This causes generic/257 xfstest to fail. Fix this by triggering the end of search by this error code in SMB2_query_directory. Also when negotiating CIFS protocol we tell the server to close the search automatically at the end and there is no need to do it itself. In the case of SMB2 protocol, we need to close it explicitly - separate close directory checks for different protocols. Signed-off-by: Pavel Shilovsky <pshilovsky@samba.org> Signed-off-by: Steve French <smfrench@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CIFS: Fix wrong restart readdir for SMB1 commit f736906a7669a77cf8cabdcbcf1dc8cb694e12ef upstream. The existing code calls server->ops->close() that is not right. This causes XFS test generic/310 to fail. Fix this by using server->ops->closedir() function. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Pavel Shilovsky <pshilovsky@samba.org> Signed-off-by: Steve French <smfrench@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cifs: don't instantiate new dentries in readdir for inodes that need to be revalidated immediately commit 757c4f6260febff982276818bb946df89c1105aa upstream. David reported that commit c2b93e06 (cifs: only set ops for inodes in I_NEW state) caused a regression with mfsymlinks. Prior to that patch, if a mfsymlink dentry was instantiated at readdir time, the inode would get a new set of ops when it was revalidated. After that patch, this did not occur. This patch addresses this by simply skipping instantiating dentries in the readdir codepath when we know that they will need to be immediately revalidated. The next attempt to use that dentry will cause a new lookup to occur (which is basically what we want to happen anyway). Reported-and-Tested-by: David McBride <dwm37@cam.ac.uk> Cc: "Stefan (metze) Metzmacher" <metze@samba.org> Cc: Sachin Prabhu <sprabhu@redhat.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <smfrench@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[CIFS] cifs: Rename cERROR and cFYI to cifs_dbg It's not obvious from reading the macro names that these macros are for debugging. Convert the names to a single more typical kernel style cifs_dbg macro. cERROR(1, ...) -> cifs_dbg(VFS, ...) cFYI(1, ...) -> cifs_dbg(FYI, ...) cFYI(DBG2, ...) -> cifs_dbg(NOISY, ...) Move the terminating format newline from the macro to the call site. Add CONFIG_CIFS_DEBUG function cifs_vfs_err to emit the "CIFS VFS: " prefix for VFS messages. Size is reduced ~ 1% when CONFIG_CIFS_DEBUG is set (default y) $ size fs/cifs/cifs.ko* text data bss dec hex filename 265245 2525 132 267902 4167e fs/cifs/cifs.ko.new 268359 2525 132 271016 422a8 fs/cifs/cifs.ko.old Other miscellaneous changes around these conversions: o Miscellaneous typo fixes o Add terminating \n's to almost all formats and remove them from the macros to be more kernel style like. A few formats previously had defective \n's o Remove unnecessary OOM messages as kmalloc() calls dump_stack o Coalesce formats to make grep easier, added missing spaces when coalescing formats o Use %s, __func__ instead of embedded function name o Removed unnecessary "cifs: " prefixes o Convert kzalloc with multiply to kcalloc o Remove unused cifswarn macro Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <smfrench@gmail.com>
cifs: don't compare uniqueids in cifs_prime_dcache unless server inode numbers are in use Oliver reported that commit cd60042c caused his cifs mounts to continually thrash through new inodes on readdir. His servers are not sending inode numbers (or he's not using them), and the new test in that function doesn't account for that sort of setup correctly. If we're not using server inode numbers, then assume that the inode attached to the dentry hasn't changed. Go ahead and update the attributes in place, but keep the same inode number. Cc: <stable@vger.kernel.org> # v3.5+ Reported-and-Tested-by: Oliver Mössinger <Oliver.Moessinger@ichaus.de> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
cifs: rename cifs_readdir_lookup to cifs_prime_dcache and make it void return The caller doesn't do anything with the dentry, so there's no point in holding a reference to it on return. Also cifs_prime_dcache better describes the actual purpose of the function. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <smfrench@gmail.com>
cifs: ensure we revalidate the inode after readdir if cifsacl is enabled Otherwise, "ls -l" will simply show the ownership of the files as the default mnt_uid/gid. This may make "ls -l" performance on large directories super-suck in some cases, but that's the cost of cifsacl. One possibility to make it suck less would be to somehow proactively dispatch the ACL requests asynchronously from readdir codepath, but that's non-trivial to implement. Reviewed-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <smfrench@gmail.com>
cifs: obtain file access during backup intent lookup (resend) Rebased and resending the patch. Path based queries can fail for lack of access, especially during lookup during open. open itself would actually succeed becasue of back up intent bit but queries (either path or file handle based) do not have a means to specifiy backup intent bit. So query the file info during lookup using trans2 / findfirst / file_id_full_dir_info to obtain file info as well as file_id/inode value. Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Acked-by: Jeff Layton <jlayton@samba.org> Signed-off-by: Steve French <smfrench@gmail.com>
CIFS: Replace netfid with cifs_fid struct in cifsFileInfo This is help us to extend the code for future protocols that can use another fid mechanism (as SMB2 that has it divided into two parts: persistent and violatile). Also rename variables and refactor the code around the changes. Reviewed-by: Jeff Layton <jlayton@samba.org> Signed-off-by: Pavel Shilovsky <pshilovsky@samba.org> Signed-off-by: Steve French <smfrench@gmail.com>
CIFS: Make CAP_* checks protocol independent Since both CIFS and SMB2 use ses->capabilities (server->capabilities) field but flags are different we should make such checks protocol independent. Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Pavel Shilovsky <pshilovsky@samba.org> Signed-off-by: Steve French <smfrench@gmail.com>
cifs: always update the inode cache with the results from a FIND_* When we get back a FIND_FIRST/NEXT result, we have some info about the dentry that we use to instantiate a new inode. We were ignoring and discarding that info when we had an existing dentry in the cache. Fix this by updating the inode in place when we find an existing dentry and the uniqueid is the same. Cc: <stable@vger.kernel.org> # .31.x Reported-and-Tested-by: Andrew Bartlett <abartlet@samba.org> Reported-by: Bill Robertson <bill_robertson@debortoli.com.au> Reported-by: Dion Edwards <dion_edwards@debortoli.com.au> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <smfrench@gmail.com>
cifs: Include backup intent search flags during searches {try #2) As observed and suggested by Tushar Gosavi... --------- readdir calls these function to send TRANS2_FIND_FIRST and TRANS2_FIND_NEXT command to the server. The current cifs module is not specifying CIFS_SEARCH_BACKUP_SEARCH flag while sending these command when backupuid/backupgid is specified. This can be resolved by specifying CIFS_SEARCH_BACKUP_SEARCH flag. --------- Cc: <stable@kernel.org> Reported-and-Tested-by: Tushar Gosavi <tugosavi@in.ibm.com> Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Acked-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
cifs: check for NULL last_entry before calling cifs_save_resume_key Prior to commit eaf35b1, cifs_save_resume_key had some NULL pointer checks at the top. It turns out that at least one of those NULL pointer checks is needed after all. When the LastNameOffset in a FIND reply appears to be beyond the end of the buffer, CIFSFindFirst and CIFSFindNext will set srch_inf.last_entry to NULL. Since eaf35b1, the code will now oops in this situation. Fix this by having the callers check for a NULL last entry pointer before calling cifs_save_resume_key. No change is needed for the call site in cifs_readdir as it's not reachable with a NULL current_entry pointer. This should fix: https://bugzilla.redhat.com/show_bug.cgi?id=750247 Cc: stable@vger.kernel.org Cc: Christoph Hellwig <hch@infradead.org> Reported-by: Adam G. Metzler <adamgmetzler@gmail.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <smfrench@gmail.com>
Merge git://git./linux/kernel/git/sfrench/cifs-2.6 * git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6: cifs: Cleanup: check return codes of crypto api calls CIFS: Fix oops while mounting with prefixpath [CIFS] Redundant null check after dereference cifs: use cifs_dirent in cifs_save_resume_key cifs: use cifs_dirent to replace cifs_get_name_from_search_buf cifs: introduce cifs_dirent cifs: cleanup cifs_filldir