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] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 26 Aug 2011 18:05:55 -0500
From:	Steve French <smfrench@...il.com>
To:	Justin Piszcz <jpiszcz@...idpixels.com>
Cc:	Jeff Layton <jlayton@...ba.org>,
	"J. R. Okajima" <hooanon05@...oo.co.jp>,
	Jesper Juhl <jj@...osbits.net>, linux-kernel@...r.kernel.org,
	Alan Piszcz <ap@...arrain.com>,
	Steve French <sfrench@...ba.org>, linux-cifs@...r.kernel.org
Subject: Re: Kernel 3.0: Instant kernel crash when mounting CIFS (also crashes
 with linux-3.1-rc2

On Fri, Aug 26, 2011 at 5:57 PM, Justin Piszcz <jpiszcz@...idpixels.com> wrote:
>
>
> On Fri, 26 Aug 2011, Jeff Layton wrote:
>
>> On Thu, 18 Aug 2011 14:52:57 -0400
>> Jeff Layton <jlayton@...ba.org> wrote:
>>
>>> On Thu, 18 Aug 2011 14:18:15 -0400 (EDT)
>>> Justin Piszcz <jpiszcz@...idpixels.com> wrote:
>>>
>>>>
>>> Like I said, read performance with cifs.ko just plain sucks currently.
>>>
>>> Don't look for cifs.ko to achieve anywhere near NFS' performance unless
>>> you jump through some very odd hoops (like multithreading your workload
>>> in userspace, etc). cifs.ko just doesn't do a good job of keeping the
>>> pipe "stuffed" as most calls are handled synchronously. A single task
>>> can only handle one call on the wire in most cases. The exception here
>>> is writes, but that just recently changed...
>>>
>>> Reads are done using relatively small buffers and then copied to
>>> pagecache. Part of what I'm working on will be to allow for much larger
>>> reads directly into the pagecache. That should also help performance
>>> significantly.
>>>
>>
>> I just posted a patchset that should improve the performance of
>> buffered reads. It's rather large but should apply to current upstream
>> kernels. If you've had problems with cifs.ko read performance in the
>> past, then this would be a good time to step up and help test them.
>>
>> If it makes things easier, then the patchset is also available via the
>> cifs-3.2 branch of my public git tree:
>>
>>
>> http://git.kernel.org/?p=linux/kernel/git/jlayton/linux.git;a=shortlog;h=refs/heads/cifs-3.2
>>
>> Thanks,
>> --
>> Jeff Layton <jlayton@...ba.org>
>
> Hi Jeff,
>
> This was working earlier..
>
> # mount -t cifs //10.0.1.1/x /mnt -o user=XXXXXXX,pass=XXXXXXXX
> mount error(12): Cannot allocate memory
> Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
>
> I'll need to contact the owner of the host to see if something has changed
> as this _was_ working previously.

Fails with Jeff's new 20+ patch series?


-- 
Thanks,

Steve
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ