fixed credentials file handling in mount.cifs

I fixed the problem that Kieron pointed out with the credentials file
handling in the cifs mount helper mount.cifs (the password was including
the terminating new line character).  It is updated in the samba cvs and
a new prebuilt version (for x86) is available from the project page.

I also added a mnt_opts string when cifs adds mount entries to mtab so
the output of the mount command (with no parms, ie in order to display
mount information) that read that information from the file rather than
from the kernel (ie /proc/mounts) will include some information about
the mount flags for cifs mounts. 

Viewing the information in /proc/mounts had been ok since it invokes
kernel code to display that info, and is better since it includes more
detailed information although in a similar format.

Problem mouting Win2k shares with cifsmount

I have been experiencing a problem when accessing Win2k shares using
cifsmount that has already been reported but no solution has,
apparently, been posted.

When mounting a Win2K share from a Linux workstation using the command:

mount -t cifs //192.168.200.54/test /mnt/smb -o user=TestUser

I get the error:

mount error 22 = Invalid argument

dmesg reports the following errors:

CIFS VFS: Send error in SessSetup = -13
CIFS VFS: cifs_mount failed w/return code = -13

Using "mount -t smbfs //192.168.200.54/test /mnt/smb -o
username=TestUser" correctly mounts the share confirming that TestUser
has access to the share.

Using Ethereal to sniff the network shows that when using cifs, the
Linux Win2k box replies with a "Session Setup AndX Response, Error:
STATUS_LOGON_FAILURE"

One noticeable difference between the cifs and the smbfs "Session Setup
AndX Request"  frames is that smbfs sends the encrypted password both as
ANSI and as Unicode whereas cifs only sends the password in Unicode.
Could this be the cause of the problem?

[PATCH 0/4] CIFS fixes for 2.4.x

Hello!

When trying to use cifs-1.0.2b (with kernel 2.4.25), I have found a
serious problem: while reading and writing small files seems to work
fine, trying to write a big file (about 100M) to cifs gives a bunch
of errors after several seconds:

CIFS VFS: CIFS: caught signal
CIFS VFS: Send error in write = -4

Then the system becomes unresponsive; sometimes it recovers after
several minutes.  The behavior is similar to the one described at
http://lists.samba.org/archive/samba/2004-March/082269.html.

I have found several bugs in the cifs code which lead to this
problem; the modified cifs-1.0.2b code seems to work stable when
copying big files.  Patches with descriptions are in followup
messages.

--

-- 
Sergey Vlasov

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
http://lists.samba.org/mailman/listinfo/linux-cifs-client

[PATCH 1/4] CIFS fixes for 2.4.x

This patch fixes the deadlock between cifs_demultiplex_thread() and
SendReceive().  The following backtrace was observed:

Trace; d0a6b92f <[cifs]SendReceive+6f/3fe>
Trace; d0a5a959 <[cifs]smb_init+189/1a0>
Trace; d0a5b81c <[cifs]CIFSSMBWrite+14c/1b0>
Trace; d0a659c7 <[cifs]cifs_write+127/280>
Trace; d0a65cad <[cifs]cifs_partialpagewrite+18d/250>
Trace; c01e62f9 <memcpy_toiovec+39/70>
Trace; d0a65db8 <[cifs]cifs_writepage+48/a0>
Trace; c013115c <shrink_cache+21c/3c0>
Trace; c01313e2 <refill_inactive+e2/150>
Trace; c013147f <shrink_caches+2f/40>
Trace; c01314e2 <try_to_free_pages_zone+52/e0>
Trace; c013207d <balance_classzone+4d/230>
Trace; c013240a <__alloc_pages+1aa/2b0>
Trace; c0132520 <__get_free_pages+10/20>
Trace; c012fde7 <kmem_cache_grow+a7/210>
Trace; c0130019 <kmem_cache_alloc+c9/e0>
Trace; d0a6a230 <[cifs]checkSMB+90/100>
Trace; d0a6a23c <[cifs]checkSMB+9c/100>
Trace; d0a69f01 <[cifs]cifs_buf_get+11/30>
Trace; d0a5ff45 <[cifs]cifs_demultiplex_thread+85/5d0>
Trace; c0107126 <arch_kernel_thread+26/30>
Trace; d0a5fec0 <[cifs]cifs_demultiplex_thread+0/5d0>

The problem is that cifs_demultiplex_thread() allocates memory with
GFP_KERNEL, and such allocation can trigger writeout of dirty pages
if the system decides that there is not enough free memory.  If the
memory allocator decides to write out a dirty page to the same cifs

[PATCH 2/4] CIFS fixes for 2.4.x

This patch sets sk->allocation for the cifs socket to GFP_NOFS, so
the internal memory allocations in the socket layer will not cause
attempts to reenter the cifs code for writeout of dirty pages.

I have not been able to reproduce a problem specifically related to
these allocations, however, this looks like the right way to avoid
reentrancy problems.

There was a commented out assignment to sk->allocation in smb_send()
(with a nonexistent GFP_BUFFER value) - I have deleted it and put
the setting to ipv4_connect() after the socket is created (it needs
to be done only once per socket).

--- kernel-source-cifs-1.0.2/connect.c.sock-alloc	2004-04-08 10:50:50 +0400
+++ kernel-source-cifs-1.0.2/connect.c	2004-04-08 12:54:18 +0400
 <at>  <at>  -798,6 +798,7  <at>  <at>  ipv4_connect(struct sockaddr_in *psin_se
 			return rc;
 		} else {
 		/* BB other socket options to set KEEPALIVE, NODELAY? */
+			(*csocket)->sk->allocation = GFP_NOFS;
 			cFYI(1,("Socket created"));
 		}
 	}
--- kernel-source-cifs-1.0.2/transport.c.sock-alloc	2004-02-05 05:55:30 +0300
+++ kernel-source-cifs-1.0.2/transport.c	2004-04-08 12:54:35 +0400
 <at>  <at>  -127,7 +127,6  <at>  <at>  smb_send(struct socket *ssocket, struct 

 	if(ssocket == NULL)
 		return -ENOTSOCK; /* BB eventually add reconnect code here */
-/*  ssocket->sk->allocation = GFP_BUFFER; *//* BB is this spurious? */

[PATCH 3/4] CIFS fixes for 2.4.x

This patch sets the signal mask in SendReceive() to block all
signals during this function, and also makes the wait in this
function uninterruptible.

In theory, the ability to interrupt a long FS operation with a
signal would be good (especially for a network filesystem).
However, the way it was implemented in SendReceive() does not really
work: when I applied the previous 2 patches, I still got lots of -4
(EINTR) errors when writing large files.

The problem is that writing dirty pages from the page cache is
performed asynchronously, and can happen in context of any process.
Most writes are performed by kswapd, but any process which performs
memory allocations can trigger a call to ->writepage in its own
context.  If this process receives signals, and SendReceive() uses
an interruptible wait, these signals would then interrupt the
writepage handler and cause data loss.

The signal blocking code was stolen from smbfs; it is needed to
avoid -EINTR returns from sock_sendmsg().  The big-looking part of
the patch is mostly reindenting after "if" removal (also an expicit
return was replaced by "goto cifs_no_response_exit" to perform the
proper cleanup).

--- kernel-source-cifs-1.0.2/transport.c.send-sigmask	2004-04-08 14:02:24 +0400
+++ kernel-source-cifs-1.0.2/transport.c	2004-04-08 14:18:15 +0400
 <at>  <at>  -174,6 +174,7  <at>  <at>  SendReceive(const unsigned int xid, stru
 	unsigned int receive_len;
 	long timeout = 10 * HZ;
 	struct mid_q_entry *midQ;

[PATCH 4/4] CIFS fixes for 2.4.x

This patch fixes the sock_sendmsg() handling in smb_send().

sock_sendmsg() can perform a partial write, therefore checking its
return value only for an error code is insufficient.  This patch
fixes the loop in smb_send() to handle the partial write case
correctly.

Without this patch I still experienced intermittent errors during
large file writes.

--- kernel-source-cifs-1.0.2/transport.c.send-count	2004-04-08 15:05:46 +0400
+++ kernel-source-cifs-1.0.2/transport.c	2004-04-08 15:06:45 +0400
 <at>  <at>  -149,10 +149,16  <at>  <at>  smb_send(struct socket *ssocket, struct 

 	temp_fs = get_fs();	/* we must turn off socket api parm checking */
 	set_fs(get_ds());
-	rc = sock_sendmsg(ssocket, &smb_msg, smb_buf_length + 4);
-	while((rc == -ENOSPC) || (rc == -EAGAIN)) {
-		schedule_timeout(HZ/2);
-		rc = sock_sendmsg(ssocket, &smb_msg, smb_buf_length + 4);
+	while (iov.iov_len > 0) {
+		rc = sock_sendmsg(ssocket, &smb_msg, iov.iov_len);
+		if ((rc == -ENOSPC) || (rc == -EAGAIN)) {
+			schedule_timeout(HZ/2);
+			continue;
+		}
+		if (rc < 0)
+			break;
+		iov.iov_base += rc;
+		iov.iov_len -= rc;

Re: [PATCH 0/4] CIFS fixes for 2.4.x

I get ths error too when using the current cifs bk-tree kernel, my 
system even froze several times.. ive got to investigate this a bit 
further maybe.. though before i used a 2.6.3 cifs kernel (eg a kernel 
pulled from the cifs bk tree when kernel 2.6.3 was released) and i didnt 
have this problem, at least no freezes..

Problem mounting Win2k shares with mount.cifs

Updating on my previous post:

I have been experiencing a problem when accessing Win2k shares using
mount.cifs that has already been reported but no solution has,
apparently, been posted.

When mounting a Win2K share from a Linux workstation using the command:

mount -t cifs //192.168.200.54/test /mnt/smb -o user=TestUser

I get the error:

mount error 22 = Invalid argument

I upgraded to SuSE's test kernel 2.6.4-34 and now I get the error:

mount error 13 = Permission denied

The user has access to the share and I can mount it using smbfs.

Any ideas?

cifs vfs fixes

Did a complete review of all memory allocation code (direct or indirect)
in cifs vfs.  Added misc. fixes for memory leaks in error paths (mostly
mount related).  Also have brought down to the project bk tree the
current mainline 2.6.5 tree (which broke the cifs build a few days ago
when it renamed a page struct field).  This should also allow Andrew
Morton to pick the cifs bk tree up in his mm testing tree again.

It is now in 1.07 in the project bk tree.