| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Could cause memory leak in some readpaths depending on what junk followed it in the stack.
Signed-off-by: Steve French <sfrench@us.ibm.com>
|
|
|
|
| |
Signed-off-by: Steve French <sfrench@us.ibm.com>
|
|
|
|
| |
Signed-off-by: Steve French <sfrench@us.ibm.com>
|
|
|
|
|
|
| |
memcpy. Part 1
Signed-off-by: Steve French <sfrench@us.ibm.com>
|
|
|
|
|
|
|
|
| |
the request queue. Also periodically wakeup response_q so threads can
check if stuck requests have timed out. Workaround Windows server illegal smb
length on transact2 findfirst response.
Signed-off-by: Steve French <sfrench@us.ibm.com>
|
|
|
|
|
| |
Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
|
|
|
|
|
|
| |
New cifs_writepages routine was not updated bytes written in cifs stats.
Also added ability to clear /proc/fs/cifs/Stats by writing (0 or 1) to it.
Signed-off-by: Steve French <sfrench@us.ibm.com>
|
|
|
|
|
|
|
| |
Continue implementation of cifs umount begin to allow force unmounts of
cifs mounts.
Signed-off-by: Steve French <sfrench@us.ibm.com>
|
|
|
|
|
|
|
| |
ever longer amounts (up to 15 seconds). This improves performance
especially when using large wsize.
Signed-off-by: Steve French (sfrench@us.ibm.com)
|
|
|
|
|
|
|
| |
These changes to debug code and new stats are helpful in
debugging potential tcp performance/configuration problems under cifs.
Signed-off-by: Steve French <sfrench@us.ibm.com>
|
|
|
|
|
|
|
|
| |
This allows cifs_writepages to send data in larger chunks from the page
cache, without requiring larger memory allocations in other cases.
Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
|
|
|
|
|
| |
Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
|
|
|
|
| |
Signed-off-by: Steve French (sfrench@us.ibm.com)
|
|
|
|
|
|
|
|
|
|
| |
eliminate the double copy, and improve cifs write performance and
help the server by upping the typical write size from 4K to 16K
(or even larger if wsize set explicitly) for servers which support this.
Part 1 of 2
Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
|
|
|
|
|
|
|
| |
Most important of these fixes mapchars on bigendian and a few statfs fields
Signed-off-by: Shaggy (shaggy@austin.ibm.com)
Signed-off-by: Steve French (sfrench@us.ibm.com)
|
|
|
|
|
|
| |
Fix some compiler warnings noticed on x64 by me and ppc64 by Shaggy
Signed-off-by: Steve French (sfrench@us.ibm.com)
|
|
|
|
|
|
| |
missing. Most importantly SMB reads were undercounted.
Signed-off-by: Steve French (sfrench@us.ibm.com)
|
|
|
|
| |
Signed-off-by: Steve French (sfrench@us.ibm.com)
|
|
|
|
| |
Signed-off-by: Steve French (sfrench@us.ibm.com)
|
|
|
|
|
|
|
|
|
|
| |
if cifsd thread is no longer running to demultixplex responses.
Do not send FindClose request when FindFirst failed without reaching end
of search.
Signed-off-by: Steve French (sfrench@us.ibm.com)
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
|
|
|
| |
Signed-off-by: Steve French (sfrench@us.ibm.com)
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
|
|
|
|
|
|
|
| |
unless response is larger than 256 bytes. This cuts more than 1/3 of
the large memory allocations that cifs does and should be a huge help to
memory pressure under stress.
Signed-off-by: Steve French (sfrench@us.ibm.com)
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
|
|
|
|
|
|
|
| |
unrelated command
.. even if the multiplex ids match.
Signed-off-by: Steve French (sfrench@us.ibm.com)
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
|
|
|
|
|
| |
and mac session key
Signed-off-by: Steve French (sfrench@us.ibm.com)
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|