gmane.linux.file-systems.cifs

Re: problems with signing and new crypto code

Shirish Pargaonkar — 2011-06-17T13:58:40

Jeff, no I have not seen this. You think some iozone testing against
a Windows server with the latest cifs code might expose this problem?
I will try both Windows 2003 server and Windows 2008 server.

cifs_sign_smb and cifs_sign_smb2 do the same exact thing except that
the messages that gets used in signature calculation are different in these
routines.

My initial thought was/is the same as yours, the content of message
used in calculating signature is different at the server and client resulting
in different signatures hence dropped smb connection by the server.
But it is possible cifs_sign_smb2 and/or cifs_calc_signature2 have a bug!

Regards,

Shirish

problems with signing and new crypto code

Jeff Layton — 2011-06-17T13:06:56

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

Re: [PATCH] cifs: allow callingcifs_build_path_to_root on incomplete cifs_sb

Darren Williams — 2011-02-16T08:22:25

Hi All

Robert and Jeff thanks for working on and fixing this, I can confirm 
that we now have;
- Remote DFS mounts working, using
- both sec=krb5 and sec=ntlm.

I'm just looking for clarification on the following feature or bug:

we have a SAMBA server, samba1, serving a DFS root as follows

[dfs]
    path = /export/samba/dfs
    msdfs root = yes

configured as:

ls -l /export/samba/dfs
total 8
lrwxrwxrwx 1 root root 79 2010-03-10 07:53 home -> 
msdfs:samba1\dfshome,samba2\dfshome

and SAMBA servers, samba1 and samba2 with shares:

[dfshome]
    comment = DFS Linux Home Directories
    path = /export/home/1/%u
    create mask = 0700
    force create mode = 0700
    directory mask = 0700
    force directory mode = 0700
    read only = No
    browseable = No
    valid users = %U
    map acl inherit = yes



If I cifs mount the DFS root using
mount.cifs //samba1/dfs /tmp/dfs -o <options as required>
then list the directory I get the following errors:


root< at >atp-h5gcn1s:~# mount.cifs //samba1/dfs /tmp/dfs/ -o <

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

Volker Lendecke — 2011-01-27T18:39:35

Good question. There has been a subtle bug in smbclient in
that it did not send out requests as fast as it could (the
events system did not prefer writes over reads). You could
be hitting this bug. But I'd need to analyze this much
closer with an strace -ttT of smbclient and smbd, and a
wireshark trace.

With best regards,

Volker Lendecke

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

Emmanuel Florac — 2011-01-27T18:07:19

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?

[PATCH 4/4] cifs: remove/proc/fs/cifs/Experimental

Jeff Layton — 2010-12-07T14:22:17

This flag only affects a couple of places in the write codepath, and
it's not entirely clear to me what the purpose of it is. I've never
known anyone (even developers) to use this knob, so let's remove it.

Signed-off-by: Jeff Layton <jlayton< at >redhat.com>
---
 fs/cifs/cifs_debug.c |   42 ------------------------------------------
 fs/cifs/cifsfs.c     |    1 -
 fs/cifs/cifsglob.h   |    1 -
 fs/cifs/file.c       |    6 +++---
 4 files changed, 3 insertions(+), 47 deletions(-)

diff --git a/fs/cifs/cifs_debug.c b/fs/cifs/cifs_debug.c
index 103ab8b..04eecb2 100644
--- a/fs/cifs/cifs_debug.c
+++ b/fs/cifs/cifs_debug.c
< at >< at > -425,7 +425,6 < at >< at > static const struct file_operations cifs_lookup_cache_proc_fops;
 static const struct file_operations traceSMB_proc_fops;
 static const struct file_operations cifs_multiuser_mount_proc_fops;
 static const struct file_operations cifs_security_flags_proc_fops;
-static const struct file_operations cifs_experimental_proc_fops;
 static const struct file_operations cifs_linux_ext_proc

[PATCH 3/4] cifs: removeCIFSSMBQueryReparseLinkInfo and CONFIG_CIFS_EXPERIMENTAL

Jeff Layton — 2010-12-07T14:22:16

Nothing calls this function. Remove it.

With this, the last user of CONFIG_CIFS_EXPERIMENTAL has been
removed. Also, update the README.

Signed-off-by: Jeff Layton <jlayton< at >redhat.com>
---
 fs/cifs/Kconfig     |   13 ------
 fs/cifs/README      |   12 ------
 fs/cifs/cifsproto.h |    6 ---
 fs/cifs/cifssmb.c   |  104 ---------------------------------------------------
 4 files changed, 0 insertions(+), 135 deletions(-)

diff --git a/fs/cifs/Kconfig b/fs/cifs/Kconfig
index ee45648..27917a5 100644
--- a/fs/cifs/Kconfig
+++ b/fs/cifs/Kconfig
< at >< at > -151,16 +151,3 < at >< at > config CIFS_ACL
     Allows to fetch CIFS/NTFS ACL from the server.  The DACL blob
     is handed over to the application/caller.
 
-config CIFS_EXPERIMENTAL
-  bool "CIFS Experimental Features (EXPERIMENTAL)"
-  depends on CIFS && EXPERIMENTAL
-  help
-    Enables cifs features under testing. These features are
-    experimental and currently include DFS support and directory
-    change notification ie fcntl(F_DNOTIFY), as well as the upcall

[PATCH 2/4] cifs: move "ntlmssp" and"local_leases" options out of experimental code

Jeff Layton — 2010-12-07T14:22:15

I see no real need to leave these sorts of options under an
EXPERIMENTAL ifdef. Since you need a mount option to turn this code
on, that only blows out the testing matrix.

local_leases has been under the EXPERIMENTAL tag for some time, but
it's only the mount option that's under this label. Move it out
from under this tag.

The NTLMSSP code is also under EXPERIMENTAL, but it needs a mount
option to turn it on, and in the future any distro will reasonably
want this enabled. Go ahead and move it out from under the
EXPERIMENTAL tag.

Signed-off-by: Jeff Layton <jlayton< at >redhat.com>
---
 fs/cifs/cifssmb.c |    5 +--
 fs/cifs/connect.c |    4 --
 fs/cifs/sess.c    |  103 ++++++++++++++++++++++++-----------------------------
 3 files changed, 48 insertions(+), 64 deletions(-)

diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index d7957a3..4df1d10 100644
--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
< at >< at > -401,15 +401,12 < at >< at > CIFSSMBNegotiate(unsigned int xid, struct cifsSesInfo *ses)
 else if ((secFlags & CIFSSEC

[PATCH 1/4] cifs: remove export_ops code

Jeff Layton — 2010-12-07T14:22:14

Stubs for this code were added under the CONFIG_CIFS_EXPERIMENTAL tag in
2007, but were never completed. The upshot -- anyone who turns on
CONFIG_CIFS_EXPERIMENTAL gets a filesystem that pretends to allow exporting
via nfsd. Trying to actually use it will just get you an error once
nfsd tries to walk into the directory.

Remove this code since it's unfinished. We can reintroduce it once someone
spends time on it and makes it usable.

Signed-off-by: Jeff Layton <jlayton< at >redhat.com>
---
 fs/cifs/Makefile |    2 +-
 fs/cifs/cifsfs.c |    7 -----
 fs/cifs/cifsfs.h |    4 ---
 fs/cifs/export.c |   67 ------------------------------------------------------
 4 files changed, 1 insertions(+), 79 deletions(-)
 delete mode 100644 fs/cifs/export.c

diff --git a/fs/cifs/Makefile b/fs/cifs/Makefile
index 43b19dd..ee8a33c 100644
--- a/fs/cifs/Makefile
+++ b/fs/cifs/Makefile
< at >< at > -6,7 +6,7 < at >< at > obj-$(CONFIG_CIFS) += cifs.o
 cifs-y := cifsfs.o cifssmb.o cifs_debug.o connect.o dir.o file.o inode.o \
   link.o misc.o netmisc.o sm

[PATCH 0/4] cifs: CONFIG_CIFS_EXPERIMENTALremoval

Jeff Layton — 2010-12-07T14:22:13

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

[PATCH] cifs: allow callingcifs_build_path_to_root on incomplete cifs_sb

Jeff Layton — 2010-12-06T12:13:03

It's possible that cifs_mount will call cifs_build_path_to_root on a
newly instantiated cifs_sb. In that case, it's likely that the
master_tlink pointer has not yet been instantiated.

Fix this by having cifs_build_path_to_root take a cifsTconInfo pointer
as well, and have the caller pass that in.

Reported-by: Robbert Kouprie <robbert< at >exx.nl>
Signed-off-by: Jeff Layton <jlayton< at >redhat.com>
---
 fs/cifs/cifsproto.h |    3 ++-
 fs/cifs/connect.c   |    2 +-
 fs/cifs/inode.c     |    6 +++---
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/fs/cifs/cifsproto.h b/fs/cifs/cifsproto.h
index f4cc34f..4e65b67 100644
--- a/fs/cifs/cifsproto.h
+++ b/fs/cifs/cifsproto.h
< at >< at > -54,7 +54,8 < at >< at > do {\
      __func__, curr_xid, (int)rc);\
 } while (0)
 extern char *build_path_from_dentry(struct dentry *);
-extern char *cifs_build_path_to_root(struct cifs_sb_info *cifs_sb);
+extern char *cifs_build_path_to_root(struct cifs_sb_info *cifs_sb,
+struct cifsTconInfo *tcon);
 extern char *build_wildcar

REMINDER: the old linux-cifs-client list is nowdeprecated

Jeff Layton — 2010-06-19T10:58:26

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!

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

Jeff Layton — 2010-06-16T13:38:13

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

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

Jeff Layton — 2010-06-12T10:29:02

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

Re: [PATCH] cifs: hard mount option behaviour

Steve French — 2010-06-08T14:24:51

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

Re: [PATCH] accept all supported values for dir_mode

Jeff Layton — 2010-06-07T11:24:09

On Mon, 7 Jun 2010 00:20:14 -0400
Scott Lovenberg <scott.lovenberg< at >gmail.com> wrote:


I think we're stuck living with it like this. The maintenance burden on
this sort of thing is fairly low so it's not really a big deal. This is
a good reason why we have to consider user-visible interfaces very
carefully however.

Re: [PATCH] accept all supported values fordir_mode

Scott Lovenberg — 2010-06-07T04:20:14

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

Re: [PATCH] accept all supported values for dir_mode

Jeff Layton — 2010-06-06T11:33:03

On Thu,  3 Jun 2010 02:39:19 -0400
Scott Lovenberg <scott.lovenberg< at >gmail.com> wrote:

      ^^^^
Sigh. But I can confirm that this is similarly broken in the kernel
so we have little choice but to live with it here.



Committed...

Re: Question about fsid.

Jeff Layton — 2010-06-06T10:54:40

On Sat, 5 Jun 2010 19:02:46 +0200
Stef Bon <stefbon< at >gmail.com> wrote:


Because the statfs call for CIFS doesn't fill it out. The rabbit hole
begins at cifs_statfs().

Question about fsid.

Stef Bon — 2010-06-05T17:02:46

Hello,

I found out that a stat call:

stat -f  %directory%

gives zero for a cifs mounts.

Why is that?

Stef

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

Jeff Layton — 2010-06-05T13:35:58

On Sat, 5 Jun 2010 08:35:42 -0400
Scott Lovenberg <scott.lovenberg< at >gmail.com> wrote:


Getting patchwork switched over is on my to-do list.