kernel.git/fs/cifs/dir.c, branch linux-3.3.y

CIFS: Respect negotiated MaxMpxCount

2012-04-02T17:32:07Z

commit 10b9b98e41ba248a899f6175ce96ee91431b6194 upstream. Some servers sets this value less than 50 that was hardcoded and we lost the connection if when we exceed this limit. Fix this by respecting this value - not sending more than the server allows. Reviewed-by: Jeff Layton Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman

cifs: fix dentry refcount leak when opening a FIFO on lookup

2012-02-27T05:16:26Z

The cifs code will attempt to open files on lookup under certain circumstances. What happens though if we find that the file we opened was actually a FIFO or other special file? Currently, the open filehandle just ends up being leaked leading to a dentry refcount mismatch and oops on umount. Fix this by having the code close the filehandle on the server if it turns out not to be a regular file. While we're at it, change this spaghetti if statement into a switch too. Cc: stable@vger.kernel.org Reported-by: CAI Qian Tested-by: CAI Qian Reviewed-by: Shirish Pargaonkar Signed-off-by: Jeff Layton Signed-off-by: Steve French

cifs: request oplock when doing open on lookup

2012-02-08T04:25:29Z

Currently, it's always set to 0 (no oplock requested). Cc: Signed-off-by: Jeff Layton Signed-off-by: Steve French

switch ->mknod() to umode_t

2012-01-04T03:54:54Z

Signed-off-by: Al Viro

switch ->create() to umode_t

2012-01-04T03:54:53Z

vfs_create() ignores everything outside of 16bit subset of its mode argument; switching it to umode_t is obviously equivalent and it's the only caller of the method Signed-off-by: Al Viro

CIFS: fix automount for DFS shares

2011-10-18T15:49:38Z

Automounting directories are now invalidated by .d_revalidate() so to be d_instantiate()d again with the right DCACHE_NEED_AUTOMOUNT flag Reviewed-by: Jeff Layton Signed-off-by: Gerlando Falauto Signed-off-by: Steve French

cifs: Add mount options for backup intent (try #6)

2011-10-13T04:42:17Z

Add mount options backupuid and backugid. It allows an authenticated user to access files with the intent to back them up including their ACLs, who may not have access permission but has "Backup files and directories user right" on them (by virtue of being part of the built-in group Backup Operators. When mount options backupuid is specified, cifs client restricts the use of backup intents to the user whose effective user id is specified along with the mount option. When mount options backupgid is specified, cifs client restricts the use of backup intents to the users whose effective user id belongs to the group id specified along with the mount option. If an authenticated user is not part of the built-in group Backup Operators at the server, access to such files is denied, even if allowed by the client. Signed-off-by: Shirish Pargaonkar Reviewed-by: Jeff Layton Signed-off-by: Steve French

add new module parameter 'enable_oplocks'

2011-10-13T04:42:05Z

Thus spake Jeff Layton: "Making that a module parm would allow you to set that parameter at boot time without needing to add special startup scripts. IMO, all of the procfile "switches" under /proc/fs/cifs should be module parms instead." This patch doesn't alter the default behavior (Oplocks are enabled by default). To disable oplocks when loading the module, use modprobe cifs enable_oplocks=0 (any of '0' or 'n' or 'N' conventions can be used). To disable oplocks at runtime using the new interface, use echo 0 > /sys/module/cifs/parameters/enable_oplocks The older /proc/fs/cifs/OplockEnabled interface will be deprecated after two releases. A subsequent patch will add an warning message about this deprecation. Changes since v2: - make enable_oplocks a 'bool' Changes since v1: - eliminate the use of extra variable by renaming the old one to enable_oplocks and make it an 'int' type. Reported-by: Alexander Swen Reviewed-by: Jeff Layton Signed-off-by: Suresh Jayaraman Signed-off-by: Steve French

cifs: demote cERROR in build_path_from_dentry to cFYI

2011-08-16T13:07:24Z

Running the cthon tests on a recent kernel caused this message to pop occasionally: CIFS VFS: did not end path lookup where expected namelen is 0 Some added debugging showed that namelen and dfsplen were both 0 when this occurred. That means that the read_seqretry returned true. Assuming that the comment inside the if statement is true, this should be harmless and just means that we raced with a rename. If that is the case, then there's no need for alarm and we can demote this to cFYI. While we're at it, print the dfsplen too so that we can see what happened here if the message pops during debugging. Cc: stable@kernel.org Cc: Al Viro Signed-off-by: Jeff Layton Signed-off-by: Steve French

Merge git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6

2011-07-26T18:11:28Z

* 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