linux-kernel - Re: 2.6.31-rc8: CIFS with 5 seconds hiccups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20090918102418.5d84931e@tlielax.poochiereds.net>
Date:	Fri, 18 Sep 2009 10:24:18 -0400
From:	Jeff Layton <jlayton@...hat.com>
To:	Christoph Lameter <cl@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, samba@...ts.samba.org,
	linux-cifs-client@...ts.samba.org
Subject: Re: 2.6.31-rc8: CIFS with 5 seconds hiccups

On Wed, 16 Sep 2009 12:26:04 -0400 (EDT)
Christoph Lameter <cl@...ux-foundation.org> wrote:

> On Tue, 15 Sep 2009, Jeff Layton wrote:
> 
> > Yow, that version of mount.cifs is really old. I wonder if it may be
> > passing bad mount options to the kernel? Might be interesting to strace
> > that. Something like:
> >
> > # strace -f -s 256 -e mount mount -t cifs //chiprodfs2/company /mnt -ouser=clameter,domain=xxx
> >
> > ...it'll probably have a cleartext password in it so you might want to
> > doctor the options a bit before sending along if you do.
> >
> > Alternately, you might just want to try a newer version of mount.cifs
> > and see whether that fixes this.
> 
> Tried a newer version of mount.cifs without any change.
> 

Ok, good to rule that out then.

> > > I cannot mount the clameter dir on the 32 bit box. Hangs. So I will mount
> > > /company.
> > >
> >
> > Actually, the trace of a hanging mount would probably be interesting.
> >
> > Does the 32-bit capture that you sent represent a mount attempt that
> > hung? Or was it successful?
> 
> No it was successful.
> 

Hmm, ok. That isn't going to tell me as much as a mount that fails. For
now, I suggest that we focus on determining why these mounts hang/fail.
After that we can see whether the solution there has any bearing on why
the server is so slow to respond to this particular client.

> > What's the "devname" that you're giving to the mount command for the
> > "clameter" dir? If there's more than 1 path component after the
> > hostname, then the problem may be in the old version of mount.cifs.
> > Some of them had broken handling for path prefixes.
> 
> its //machinename/company/clameter
> 
> So two components.
> 

Also good to know.

What we should probably do at this point is track down why the 32-bit
client has such a hard time mounting the clameter dir. Here's what
would be most helpful:

1) some debug log info of the mount attempt:

# modprobe cifs
# echo 7 > /proc/fs/cifs/cifsFYI

...then attempt the mount. After it hangs for a few seconds, ^c the
mount to kill it. Collect the output from dmesg and send it to me. That
should give me some idea of what the client is doing during this phase.

If you can simultaneously capture wire traffic during the same mount
attempt that would also be helpful.

Cheers,
-- 
Jeff Layton <jlayton@...hat.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/