linux-toradex.git/fs/cifs, branch tegra-11.2.10

cifs: fix parsing of hostname in dfs referrals

2010-12-09T21:33:15+00:00

commit ba03864872691c0bb580a7fb47388da337ef4aa2 upstream.

The DFS referral parsing code does a memchr() call to find the '\\'
delimiter that separates the hostname in the referral UNC from the
sharename. It then uses that value to set the length of the hostname via
pointer subtraction.  Instead of subtracting the start of the hostname
however, it subtracts the start of the UNC, which causes the code to
pass in a hostname length that is 2 bytes too long.

Regression introduced in commit 1a4240f4.

Reported-and-Tested-by: Robbert Kouprie 
Signed-off-by: Jeff Layton 
Cc: Wang Lei 
Cc: David Howells 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

cifs: fix another memleak, in cifs_root_iget

2010-12-09T21:33:15+00:00

commit a7851ce73b9fdef53f251420e6883cf4f3766534 upstream.

cifs_root_iget allocates full_path through
cifs_build_path_to_root, but fails to kfree it upon
cifs_get_inode_info* failure.

Make all failure exit paths traverse clean up
handling at the end of the function.

Signed-off-by: Oskar Schirmer 
Reviewed-by: Jesper Juhl 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

cifs: fix broken oplock handling

2010-11-22T19:03:02+00:00

commit aa91c7e4ab9b0842b7d7a7cbf8cca18b20df89b5 upstream.

cifs_new_fileinfo() does not use the 'oplock' value from the callers. Instead,
it sets it to REQ_OPLOCK which seems wrong. We should be using the oplock value
obtained from the Server to set the inode's clientCanCacheAll or
clientCanCacheRead flags. Fix this by passing oplock from the callers to
cifs_new_fileinfo().

This change dates back to commit a6ce4932 (2.6.30-rc3). So, all the affected
versions will need this fix. Please Cc stable once reviewed and accepted.

Reviewed-by: Jeff Layton 
Signed-off-by: Suresh Jayaraman 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

cifs: prevent infinite recursion in cifs_reconnect_tcon

2010-10-01T17:50:08+00:00

cifs_reconnect_tcon is called from smb_init. After a successful
reconnect, cifs_reconnect_tcon will call reset_cifs_unix_caps. That
function will, in turn call CIFSSMBQFSUnixInfo and CIFSSMBSetFSUnixInfo.
Those functions also call smb_init.

It's possible for the session and tcon reconnect to succeed, and then
for another cifs_reconnect to occur before CIFSSMBQFSUnixInfo or
CIFSSMBSetFSUnixInfo to be called. That'll cause those functions to call
smb_init and cifs_reconnect_tcon again, ad infinitum...

Break the infinite recursion by having those functions use a new
smb_init variant that doesn't attempt to perform a reconnect.

Reported-and-Tested-by: Michal Suchanek 
Signed-off-by: Jeff Layton 
Signed-off-by: Steve French

cifs: set backing_dev_info on new S_ISREG inodes

2010-09-29T19:23:23+00:00

Testing on very recent kernel (2.6.36-rc6) made this warning pop:

    WARNING: at fs/fs-writeback.c:87 inode_to_bdi+0x65/0x70()
    Hardware name:
    Dirtiable inode bdi default != sb bdi cifs

...the following patch fixes it and seems to be the obviously correct
thing to do for cifs.

Cc: stable@kernel.org
Acked-by: Dave Kleikamp 
Signed-off-by: Jeff Layton 
Signed-off-by: Steve French

cifs: fix potential double put of TCP session reference

2010-09-14T23:21:03+00:00

cifs_get_smb_ses must be called on a server pointer on which it holds an
active reference. It first does a search for an existing SMB session. If
it finds one, it'll put the server reference and then try to ensure that
the negprot is done, etc.

If it encounters an error at that point then it'll return an error.
There's a potential problem here though. When cifs_get_smb_ses returns
an error, the caller will also put the TCP server reference leading to a
double-put.

Fix this by having cifs_get_smb_ses only put the server reference if
it found an existing session that it could use and isn't returning an
error.

Cc: stable@kernel.org
Reviewed-by: Suresh Jayaraman 
Signed-off-by: Jeff Layton 
Signed-off-by: Steve French

cifs: prevent possible memory corruption in cifs_demultiplex_thread

2010-09-08T21:22:35+00:00

cifs_demultiplex_thread sets the addr.sockAddr.sin_port without any
regard for the socket family. While it may be that the error in question
here never occurs on an IPv6 socket, it's probably best to be safe and
set the port properly if it ever does.

Break the port setting code out of cifs_fill_sockaddr and into a new
function, and call that from cifs_demultiplex_thread.

Signed-off-by: Jeff Layton 
Signed-off-by: Steve French

cifs: eliminate some more premature cifsd exits

2010-09-08T21:22:33+00:00

If the tcpStatus is still CifsNew, the main cifs_demultiplex_loop can
break out prematurely in some cases. This is wrong as we will almost
always have other structures with pointers to the TCP_Server_Info. If
the main loop breaks under any other condition other than tcpStatus ==
CifsExiting, then it'll face a use-after-free situation.

I don't see any reason to treat a CifsNew tcpStatus differently than
CifsGood. I believe we'll still want to attempt to reconnect in either
case. What should happen in those situations is that the MIDs get marked
as MID_RETRY_NEEDED. This will make CIFSSMBNegotiate return -EAGAIN, and
then the caller can retry the whole thing on a newly reconnected socket.
If that fails again in the same way, the caller of cifs_get_smb_ses
should tear down the TCP_Server_Info struct.

Signed-off-by: Jeff Layton 
Signed-off-by: Steve French

cifs: prevent cifsd from exiting prematurely

2010-09-08T21:22:30+00:00

When cifs_demultiplex_thread exits, it does a number of cleanup tasks
including freeing the TCP_Server_Info struct. Much of the existing code
in cifs assumes that when there is a cisfSesInfo struct, that it holds a
reference to a valid TCP_Server_Info struct.

We can never allow cifsd to exit when a cifsSesInfo struct is still
holding a reference to the server. The server pointers will then point
to freed memory.

This patch eliminates a couple of questionable conditions where it does
this.  The idea here is to make an -EINTR return from kernel_recvmsg
behave the same way as -ERESTARTSYS or -EAGAIN. If the task was
signalled from cifs_put_tcp_session, then tcpStatus will be CifsExiting,
and the kernel_recvmsg call will return quickly.

There's also another condition where this can occur too -- if the
tcpStatus is still in CifsNew, then it will also exit if the server
closes the socket prematurely.  I think we'll probably also need to fix
that situation, but that requires a bit more consideration.

Signed-off-by: Jeff Layton 
Signed-off-by: Steve French

[CIFS] ntlmv2/ntlmssp remove-unused-function CalcNTLMv2_partial_mac_key

2010-09-08T21:17:29+00:00

This function is not used, so remove the definition and declaration.

Reviewed-by: Jeff Layton 
Signed-off-by: Shirish Pargaonkar 
Signed-off-by: Steve French