Jeff Layton | 17 Jun 15:06 2011
Picon

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)

Emmanuel Florac | 27 Jan 19:07 2011

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
------------------------------------------------------------------------
Jeff Layton | 7 Dec 15:22 2010
Picon

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

Stephen Rothwell | 16 Jul 01:51 2010
Picon
Picon

linux-next: build failure after merge of the cifs tree

Hi Steve,

After merging the cifs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

In file included from fs/cifs/cifsfs.c:50:
fs/cifs/fscache.h:49: error: expected identifier or '(' before '{' token

Caused by commit 07be494ba2f46852ec6d1faab8111f5179cc7bb4 ("cifs: define
server-level cache index objects and register them").
CONFIG_CIFS_FSCACHE is not defined in this build.

I have used the cifs tree from next-20100715 for today.
--

-- 
Cheers,
Stephen Rothwell                    sfr <at> canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
Andrew Hendry | 26 Jun 12:46 2010
Picon

2.6.34-rc3 BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 cifs_show_options

From 2.6.34-rc3
Can't reliably reproduce, this was once after a resume over a few days
normal use.
The No response for cmds lines are normal as NAS takes a while to spin
up after resume.
System was unstable after message so couldn't collect more state

[18446744028.633263] r8169 0000:0b:02.0: eth0: link up
[18446744039.623540] eth0: no IPv6 routers present
[18446744041.684522] CIFS VFS: No response for cmd 117 mid 21812
[18446744041.684561] CIFS VFS: cifs_mount failed w/return code = -11
[18446744056.674016] CIFS VFS: No response for cmd 114 mid 21813
[18446744056.674105] CIFS VFS: cifs_mount failed w/return code = -112
[18446744060.831668] BUG: unable to handle kernel NULL pointer
dereference at 0000000000000048
[18446744060.831680] IP: [<ffffffffa02982d9>]
cifs_show_options+0xf9/0x480 [cifs]
[18446744060.831699] PGD 2068fe067 PUD 2068fd067 PMD 0
[18446744060.831710] Oops: 0000 [#1] PREEMPT SMP
[18446744060.831720] last sysfs file:
/sys/devices/system/cpu/sched_smt_power_savings
[18446744060.831729] CPU 4
[18446744060.831733] Modules linked in: nls_cp437 cifs fbcon tileblit
font bitblit softcursor binfmt_misc kvm_intel kvm snd_hda_codec_via
snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss nouveau
snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi
snd_rawmidi snd_seq_midi_event ttm psmouse snd_seq drm_kms_helper
snd_timer snd_seq_device serio_raw snd drm asus_atk0110 soundcore
snd_page_alloc i2c_algo_bit usbhid hid ahci r8169 mii libahci
pata_jmicron
(Continue reading)

Justin P. Mattock | 19 Jun 22:47 2010
Picon

[PATCH 3/6 v2]cifs Fix warnings variables set but not used

This is a resend of the original, to fix whitespace issues
and to maybe do a better job with the issue.

The patch below fixes the warning messages from
gcc 4.6.0 and compiling the kernel.
  CC [M]  fs/cifs/cifssmb.o
fs/cifs/cifssmb.c: In function 'CIFSSMBSetFileSize':
fs/cifs/cifssmb.c:4855:8: warning: variable 'data_offset' set but not used
  CC [M]  fs/cifs/cifs_debug.o

  CC [M]  fs/cifs/dir.o
fs/cifs/dir.c: In function 'cifs_lookup':
fs/cifs/dir.c:641:15: warning: variable 'filp' set but not used

  CC [M]  fs/cifs/file.o
fs/cifs/file.c: In function 'cifs_partialpagewrite':
fs/cifs/file.c:1315:23: warning: variable 'pTcon' set but not used

 Signed-off-by: Justin P. Mattock <justinmattock <at> gmail.com>

---
 fs/cifs/cifssmb.c |    2 +-
 fs/cifs/dir.c     |    3 +--
 fs/cifs/file.c    |    2 +-
 3 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index c65c341..197349c 100644
--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
(Continue reading)

Jeff Layton | 19 Jun 12:58 2010
Picon

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>
Jeff Layton | 16 Jun 21:44 2010
Picon

[PATCH] mount.cifs: use original device name as-is for mtab

We don't want to alter the device name in any way for the mtab as
/bin/umount depends on the string being identical for user mounts.

Signed-off-by: Jeff Layton <jlayton@...>
---
 mount.cifs.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mount.cifs.c b/mount.cifs.c
index 21ce532..51fc1a8 100644
--- a/mount.cifs.c
+++ b/mount.cifs.c
 <at>  <at>  -1953,7 +1953,7  <at>  <at>  mount_retry:
 	}

 	if (!parsed_info->nomtab)
-		rc = add_mtab(dev_name, mountpoint, parsed_info->flags, fstype);
+		rc = add_mtab(orig_dev, mountpoint, parsed_info->flags, fstype);

 mount_exit:
 	if (parsed_info) {
--

-- 
1.6.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Jeff Layton | 16 Jun 15:38 2010
Picon

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

Jeff Layton | 12 Jun 12:29 2010
Picon

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)

Steve French | 8 Jun 16:24 2010
Picon

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)


Gmane