headers
Jeff Layton | 17 Jun 2011 15:06
Picon
Favicon

problems with signing and new crypto code

Hi Shirish,

I've been working on some backports of some upstream patch series and
have run into what I think is a problem with the new crypto code. The
problem mainly seems to manifest itself as bad signatures in write
calls. This causes a win2k8 server (at least) to reject the call with
STATUS_ACCESS_DENIED and stop responding to other calls on the socket.

I did a bisect of sorts, and got to this patch:

commit ca83ce3d5b9ad321ee24f5870a77f0b21ac5a5de
Author: Jeff Layton <jlayton <at> redhat.com>
Date:   Tue Apr 12 09:13:44 2011 -0400

    cifs: don't allow mmap'ed pages to be dirtied while under writeback (try #3)

My original thought was that something was altering these pages while
they were under writeback, but I did some instrumentation and found
that not to be the case. The signature is the same before and after
the send when this occurs. A key change in this patch is that when
signing is enabled, the code started using CIFSSMBWrite2(), which
marshals up the send buffer in an array of kvecs.

That leads me to believe that the cifs_sign_smb2 codepath is busted.

I'll see if I can come up with a testcase, but I'm not that familiar
with the kernel crypto code. Is this something you've seen in your
testing? Any immediate thoughts as to where the problem may be?

--

--
(Continue reading)

Permalink | Reply | 8 comments |
headers
Emmanuel Florac | 27 Jan 2011 19:07
Favicon

can someone please explain the performance difference between mount.cifs and smbclient?


Using mount -t cifs //server/share /mnt/share between two big servers
connected with 10GigE, I've got : 115 MB/s reading, 132 MB/s writing. 
Using smbclient, I've got 450 MB/s reading, 132 MB/s writing (NFS gives
~ 260 MB/s write, 550 MB/s read on the same setup, with absolutely zero
optimisation).

Why this huge difference? BTW, why such a discrepancy between read and
write speed? 

--

-- 
------------------------------------------------------------------------
Emmanuel Florac     |   Direction technique
                    |   Intellique
                    |	<eflorac <at> intellique.com>
                    |   +33 1 78 94 84 02
------------------------------------------------------------------------
Permalink | Reply | 6 comments |
headers
Jeff Layton | 7 Dec 2010 15:22
Picon
Favicon

[PATCH 0/4] cifs: CONFIG_CIFS_EXPERIMENTAL removal

The CONFIG_CIFS_EXPERIMENTAL KConfig option is the sort of thing that
gives distro packagers nightmares. The things that live under it are
impossible to predict for someone who isn't following development
upstream.

We usually want bleeding-edge distros like Fedora to turn on these sorts
of bleeding edge features, but it's difficult for them to do so with any
confidence because so much of the code under this option is just plain
broken. If we have code that needs to be conditionally compiled in,
then it generally ought to be given its own KConfig option.

This patchset eliminates the CONFIG_CIFS_EXPERIMENTAL Kconfig option.
Code that currently resides under this option is either moved to being
built in by default or is removed from the kernel altogether.

The last patch in the series also removes /proc/fs/cifs/Experimental --
a knob that's purpose has been unclear since I've been working on CIFS.

I've tested this by building cifs.ko with a variety of different Kconfig
combinations and it seems to be OK.

I think this patchset is appropriate for 2.6.38, though I won't object
if you want to merge it sooner.

Jeff Layton (4):
  cifs: remove export_ops code
  cifs: move "ntlmssp" and "local_leases" options out of experimental
    code
  cifs: remove CIFSSMBQueryReparseLinkInfo and CONFIG_CIFS_EXPERIMENTAL
  cifs: remove /proc/fs/cifs/Experimental
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jeff Layton | 19 Jun 2010 12:58
Picon
Favicon

REMINDER: the old linux-cifs-client list is now deprecated

If you're receiving this email, then you are currently subscribed to
the linux-cifs-client <at> lists.samba.org mailing list. As of today, this
list is officially deprecated. The new mailing list is now
linux-cifs <at> vger.kernel.org. New posts to the old list are no longer
allowed and we will soon begin mass unsubscribing all members of the
old list.

Thank you for your patience!
--

-- 
Jeff Layton <jlayton <at> samba.org>
Permalink | Reply | 0 comments |
headers
Jeff Layton | 16 Jun 2010 15:38
Picon
Favicon

[PATCH] cifs: remove bogus first_time check in NTLMv2 session setup code

This bug appears to be the result of a cut-and-paste mistake from the
NTLMv1 code. The function to generate the MAC key was commented out, but
not the conditional above it. The conditional then ended up causing the
session setup key not to be copied to the buffer unless this was the
first session on the socket, and that made all but the first NTLMv2
session setup fail.

Fix this by removing the conditional and all of the commented clutter
that made it difficult to see.

Cc: Stable <stable <at> kernel.org>
Reported-by: Gunther Deschner <gdeschne <at> redhat.com>
Signed-off-by: Jeff Layton <jlayton <at> redhat.com>
---
 fs/cifs/sess.c |   10 +---------
 1 files changed, 1 insertions(+), 9 deletions(-)

diff --git a/fs/cifs/sess.c b/fs/cifs/sess.c
index 7707389..0a57cb7 100644
--- a/fs/cifs/sess.c
+++ b/fs/cifs/sess.c
 <at>  <at>  -730,15 +730,7  <at>  <at>  ssetup_ntlmssp_authenticate:

 		/* calculate session key */
 		setup_ntlmv2_rsp(ses, v2_sess_key, nls_cp);
-		if (first_time) /* should this be moved into common code
-				   with similar ntlmv2 path? */
-		/*   cifs_calculate_ntlmv2_mac_key(ses->server->mac_signing_key,
-				response BB FIXME, v2_sess_key); */
-
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Layton | 12 Jun 2010 12:29
Picon
Favicon

REMINDER: linux-cifs-client <at> lists.samba.org is moving to linux-cifs <at> vger.kernel.org

If you're receiving this email then you are likely a subscriber of
linux-cifs-client <at> lists.samba.org. Please read on to make sure that you
continue to receive emails for this list.

WHAT IS CHANGING AND WHY:
-------------------------
This mailing list (linux-cifs-client <at> lists.samba.org) is moving to
linux-cifs <at> vger.kernel.org. The main reasons are that vger has very good
spam filtering, nearly unlimited bandwidth and an open posting policy
for non-subscribers.

WHAT YOU NEED TO DO:
--------------------
If you wish to remain a subscriber of the list. You should immediately
subscribe to the new list. Details of how to do that are here:

    http://vger.kernel.org/vger-lists.html#linux-cifs

Please subscribe to the new list by June 19th, 2010.

SENDING POSTS DURING THE INTERIM:
--------------------------------
Forwarding between the two lists won't work correctly, and I don't have
a lot of incentive to make it do so. In the interim, it's probably best
to send messages to both lists.

On June 19th, 2010, we will begin blocking posts to the old list from
subscribers. At that point it should be sufficient to just send to the
new list.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve French | 8 Jun 2010 16:24
Picon
Gravatar

Re: [PATCH] cifs: hard mount option behaviour

> We ought to be going to great lengths to *avoid* breaking the
> connection whenever possible as so much of the state is tied up with
> the state of the socket.

We do go to great lengths to avoid giving up on the server, but there are a
few reasons we have to give up on the server and reconnect:

1) malformed smb length errors and signing errors (because typically we can't
"resync" to the beginning of the next smb safely)

2) unresponsive servers

For unresponsive servers it is difficult to pick a perfect timeout value,
but allowing i/o to retry forever can cause system hangs, and
perhaps allow a bad firewall or rogue server to make a client
unusable.   There are cases in which pending i/o can not
be cancelled with <ctl-c>.

A typical SMB/CIFS network roundtrip takes 1ms or less.   A "slow"
response still be well under 100ms, unless on a WAN (where
1 second might be considered slow).

In the dark ages (older Windows, OS/2 etc.) 45 seconds (or half of that,
about 22 seconds) were commonly used values to decide if a server
was unresponsive/broken, but this is probably too long for modern servers.
If a server is not responding in 15 seconds to a routine request, then
something bad has happened (disk hung, server crashed,
firewall eaten a request, etc.).    Note that NFS can lose
requests (over UDP) and (for v3 and v2) and can repeat requests
since it is supposed to be idempotent which stateful protocols
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stef Bon | 5 Jun 2010 19:02
Picon

Question about fsid.

Hello,

I found out that a stat call:

stat -f  %directory%

gives zero for a cifs mounts.

Why is that?

Stef
Permalink | Reply | 1 comment |
headers
Jeff Layton | 5 Jun 2010 12:50
Picon
Favicon

linux-cifs-client <at> lists.samba.org is moving to linux-cifs <at> vger.kernel.org

If you're receiving this email then you are likely a subscriber of
linux-cifs-client <at> lists.samba.org. Please read on to make sure that you
continue to receive emails for this list.

WHAT IS CHANGING AND WHY:
-------------------------
This mailing list (linux-cifs-client <at> lists.samba.org) is moving to
linux-cifs <at> vger.kernel.org. The main reasons are that vger has very good
spam filtering, nearly unlimited bandwidth and an open posting policy
for non-subscribers.

WHAT YOU NEED TO DO:
--------------------
If you wish to remain a subscriber of the list. You should immediately
subscribe to the new list. Details of how to do that are here:

    http://vger.kernel.org/vger-lists.html#linux-cifs

Please subscribe to the new list within 14 days (by June 19th, 2010).

SENDING POSTS DURING THE INTERIM:
--------------------------------
Forwarding between the two lists won't work correctly, and I don't have
a lot of incentive to make it do so. In the interim, it's probably best
to send messages to both lists.

On June 19th, 2010, we will begin blocking posts to the old list from
subscribers. At that point it should be sufficient to just send to the
new list.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jeff Layton | 5 Jun 2010 12:31
Picon
Favicon

test email of forwarding to new list

This email is a test to make sure that forwarding from
linux-cifs-client <at> lists.samba.org to linux-cifs <at> vger.kernel.org
actually works.

Please ignore!
--

-- 
Jeff Layton <jlayton <at> samba.org>
Permalink | Reply | 0 comments |
headers
Scott Lovenberg | 3 Jun 2010 08:39
Picon
Gravatar

[PATCH] accept all supported values for dir_mode

The option parsing function now accepts all values for 'dir_mode' that are supported by the kernel side code.

Signed-off-by: Scott Lovenberg <scott.lovenberg <at> gmail.com>
---
 mount.cifs.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mount.cifs.c b/mount.cifs.c
index 65754c0..21ce532 100644
--- a/mount.cifs.c
+++ b/mount.cifs.c
 <at>  <at>  -812,7 +812,7  <at>  <at>  static int parse_opt_token(const char *token)
 		return OPT_FILE_MODE;
 	if (strncmp(token, "dmask", 5) == 0)
 		return OPT_DMASK;
-	if (strncmp(token, "dir_mode", 8) == 0)
+	if (strncmp(token, "dir_mode", 4) == 0 || strncmp(token, "dirm", 4) == 0)
 		return OPT_DIR_MODE;
 	if (strncmp(token, "nosuid", 6) == 0)
 		return OPT_NO_SUID;
--

-- 
1.6.2.5
Permalink | Reply | 3 comments |

Gmane