diff options
author | Jeff Layton <jlayton@redhat.com> | 2008-02-06 01:36:43 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2008-02-06 10:41:02 -0800 |
commit | ce88cc5ed80de746f5bd2d8242291c87e7b87f63 (patch) | |
tree | ac0c1890d0f741a33c6e2cd41712ae3200bf38ea /fs/smbfs/Makefile | |
parent | 941e492bdb1239d2ca8f5736cdfd3ff83d00cb90 (diff) | |
download | op-kernel-dev-ce88cc5ed80de746f5bd2d8242291c87e7b87f63.zip op-kernel-dev-ce88cc5ed80de746f5bd2d8242291c87e7b87f63.tar.gz |
smbfs: fix calculation of kernel_recvmsg size parameter in smb_receive()
smb_receive calls kernel_recvmsg with a size that's the minimum of the
amount of buffer space in the kvec passed in or req->rq_rlen (which
represents the length of the response). This does not take into account
any data that was read in a request earlier pass through smb_receive.
If the first pass through smb_receive receives some but not all of the
response, then the next pass can call kernel_recvmsg with a size field
that's too big. kernel_recvmsg can overrun into the next response,
throwing off the alignment and making it unrecognizable.
This causes messages like this to pop up in the ring buffer:
smb_get_length: Invalid NBT packet, code=69
as well as other errors indicating that the response is unrecognizable.
Typically this is seen on a smbfs mount under heavy I/O.
This patch changes the code to use (req->rq_rlen - req->rq_bytes_recvd)
instead instead of just req->rq_rlen, since that should represent the
amount of unread data in the response.
I think this is correct, but an ACK or NACK from someone more familiar
with this code would be appreciated...
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs/smbfs/Makefile')
0 files changed, 0 insertions, 0 deletions