linux.git/fs/cifs, branch v3.11

cifs: don't instantiate new dentries in readdir for inodes that need to be revalidated immediately

2013-08-07T15:57:06+00:00

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).

Cc: 
Cc: "Stefan (metze) Metzmacher" 
Cc: Sachin Prabhu 
Reported-and-Tested-by: David McBride 
Signed-off-by: Jeff Layton 
Signed-off-by: Steve French

cifs: set sb->s_d_op before calling d_make_root()

2013-07-31T18:45:02+00:00

Currently, the s_root dentry doesn't get its d_op pointer set to
anything. This breaks lookups in the root of case-insensitive mounts
since that relies on having d_hash and d_compare routines that know to
treat the filename as case-insensitive.

cifs.ko has been broken this way for a long time, but commit 1c929cfe6
("switch cifs"), added a cryptic comment which is removed in the patch
below, which makes me wonder if this was done deliberately for some
reason. It's not clear to me why we'd want the s_root not to have d_op
set properly.

It may have something to do with d_automount or d_revalidate on the
root, but my suspicion in looking over the code is that Al was just
trying to preserve the existing behavior when changing this code over to
use s_d_op.

This patch changes it so that we set s_d_op before calling d_make_root
and removes the comment. I tested mounting, accessing and unmounting
several types of shares (including DFS referrals) and everything still
seemed to work OK afterward. I could be missing something however, so
please do let me know if I am.

Reported-by: Jan-Marek Glogowski 
Cc: Al Viro 
Cc: Ian Kent 
Signed-off-by: Jeff Layton 
Signed-off-by: Steve French

cifs: fix bad error handling in crypto code

2013-07-31T18:44:59+00:00

Jarod reported an Oops like when testing with fips=1:

CIFS VFS: could not allocate crypto hmacmd5
CIFS VFS: could not crypto alloc hmacmd5 rc -2
CIFS VFS: Error -2 during NTLMSSP authentication
CIFS VFS: Send error in SessSetup = -2
BUG: unable to handle kernel NULL pointer dereference at 000000000000004e
IP: [] crypto_destroy_tfm+0x1a/0x90
PGD 0
Oops: 0000 [#1] SMP
Modules linked in: md4 nls_utf8 cifs dns_resolver fscache kvm serio_raw virtio_balloon virtio_net mperf i2c_piix4 cirrus drm_kms_helper ttm drm i2c_core virtio_blk ata_generic pata_acpi
CPU: 1 PID: 639 Comm: mount.cifs Not tainted 3.11.0-0.rc3.git0.1.fc20.x86_64 #1
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
task: ffff88007bf496e0 ti: ffff88007b080000 task.ti: ffff88007b080000
RIP: 0010:[]  [] crypto_destroy_tfm+0x1a/0x90
RSP: 0018:ffff88007b081d10  EFLAGS: 00010282
RAX: 0000000000001f1f RBX: ffff880037422000 RCX: ffff88007b081fd8
RDX: 000000000000001f RSI: 0000000000000006 RDI: fffffffffffffffe
RBP: ffff88007b081d30 R08: ffff880037422000 R09: ffff88007c090100
R10: 0000000000000000 R11: 00000000fffffffe R12: fffffffffffffffe
R13: ffff880037422000 R14: ffff880037422000 R15: 00000000fffffffe
FS:  00007fc322f4f780(0000) GS:ffff88007fc80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000000004e CR3: 000000007bdaa000 CR4: 00000000000006e0
Stack:
 ffffffff81085845 ffff880037422000 ffff8800375e7400 ffff880037422000
 ffff88007b081d48 ffffffffa0176022 ffff880037422000 ffff88007b081d60
 ffffffffa015c07b ffff880037600600 ffff88007b081dc8 ffffffffa01610e1
Call Trace:
 [] ? __cancel_work_timer+0x75/0xf0
 [] cifs_crypto_shash_release+0x82/0xf0 [cifs]
 [] cifs_put_tcp_session+0x8b/0xe0 [cifs]
 [] cifs_mount+0x9d1/0xad0 [cifs]
 [] cifs_do_mount+0xa0/0x4d0 [cifs]
 [] mount_fs+0x39/0x1b0
 [] vfs_kern_mount+0x5f/0xf0
 [] do_mount+0x23e/0xa20
 [] ? copy_mount_options+0x36/0x170
 [] SyS_mount+0x83/0xc0
 [] system_call_fastpath+0x16/0x1b
Code: eb 9e 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 e5 41 55 41 54 49 89 fc 53 48 83 ec 08 48 85 ff 74 46 <48> 83 7e 48 00 48 8b 5e 50 74 4b 48 89 f7 e8 83 fc ff ff 4c 8b
RIP  [] crypto_destroy_tfm+0x1a/0x90
 RSP 
CR2: 000000000000004e

The cifs code allocates some crypto structures. If that fails, it
returns an error, but it leaves the pointers set to their PTR_ERR
values. Then later when it tries to clean up, it sees that those values
are non-NULL and then passes them to the routine that frees them.

Fix this by setting the pointers to NULL after collecting the error code
in this situation.

Cc: Sachin Prabhu 
Reported-by: Jarod Wilson 
Signed-off-by: Jeff Layton 
Signed-off-by: Steve French

cifs: file: initialize oparms.reconnect before using it

2013-07-31T04:54:49+00:00

In the cifs_reopen_file function, if the following statement is
asserted:

(tcon->unix_ext && cap_unix(tcon->ses) &&
            (CIFS_UNIX_POSIX_PATH_OPS_CAP &
            (tcon->fsUnixInfo.Capability)))

and we succeed to open with cifs_posix_open, the function jumps
to the label reopen_success and checks for oparms.reconnect
which is not initialized.

This issue has been reported by scan.coverity.com

Signed-off-by: Andi Shyti 
Reviewed-by: Jeff Layton 
Signed-off-by: Steve French

Do not attempt to do cifs operations reading symlinks with SMB2

2013-07-31T04:54:45+00:00

When use of symlinks is enabled (mounting with mfsymlinks option) to
non-Samba servers, we always tried to use cifs, even when we
were mounted with SMB2 or SMB3, which causes the server to drop the
network connection.

This patch separates out the protocol specific operations for cifs from
the code which recognizes symlinks, and fixes the problem where
with SMB2 mounts we attempt cifs operations to open and read
symlinks.  The next patch will add support for SMB2 for opening
and reading symlinks.  Additional followon patches will address
the similar problem creating symlinks.

Signed-off-by: Steve French

cifs: extend the buffer length enought for sprintf() using

2013-07-31T04:54:40+00:00

For cifs_set_cifscreds() in "fs/cifs/connect.c", 'desc' buffer length
is 'CIFSCREDS_DESC_SIZE' (56 is less than 256), and 'ses->domainName'
length may be "255 + '\0'".

The related sprintf() may cause memory overflow, so need extend related
buffer enough to hold all things.

It is also necessary to be sure of 'ses->domainName' must be less than
256, and define the related macro instead of hard code number '256'.

Signed-off-by: Chen Gang 
Reviewed-by: Jeff Layton 
Reviewed-by: Shirish Pargaonkar 
Reviewed-by: Scott Lovenberg 
CC: 
Signed-off-by: Steve French

CIFS: Fix a deadlock when a file is reopened

2013-07-11T23:05:41+00:00

If we request reading or writing on a file that needs to be
reopened, it causes the deadlock: we are already holding rw
semaphore for reading and then we try to acquire it for writing
in cifs_relock_file. Fix this by acquiring the semaphore for
reading in cifs_relock_file due to we don't make any changes in
locks and don't need a write access.

CC: 
Signed-off-by: Pavel Shilovsky 
Acked-by: Jeff Layton 
Signed-off-by: Steve French

CIFS: Reopen the file if reconnect durable handle failed

2013-07-11T23:05:08+00:00

This is a follow-on patch for 8/8 patch from the durable handles
series. It fixes the problem when durable file handle timeout
expired on the server and reopen returns -ENOENT for such files.
Signed-off-by: Pavel Shilovsky 
Signed-off-by: Steve French

[CIFS] Fix minor endian error in durable handle patch series

2013-07-10T18:08:55+00:00

Fix endian warning:

  CHECK   fs/cifs/smb2pdu.c
fs/cifs/smb2pdu.c:1068:40: warning: incorrect type in assignment (different base types)
fs/cifs/smb2pdu.c:1068:40:    expected restricted __le32 [usertype] Next
fs/cifs/smb2pdu.c:1068:40:    got unsigned long

Signed-off-by: Steve French

CIFS: Reconnect durable handles for SMB2

2013-07-10T18:08:40+00:00

On reconnects, we need to reopen file and then obtain all byte-range
locks held by the client. SMB2 protocol provides feature to make
this process atomic by reconnecting to the same file handle
with all it's byte-range locks. This patch adds this capability
for SMB2 shares.

Signed-off-by: Pavel Shilovsky 
Signed-off-by: Steven French