summaryrefslogtreecommitdiffstats
path: root/python/samba/sd_utils.py
diff options
context:
space:
mode:
authorStefan Metzmacher <metze@samba.org>2015-01-28 15:22:30 +0100
committerStefan Metzmacher <metze@samba.org>2015-01-29 12:31:07 +0100
commit1944c857e59922a2ebfc88a6a824a6ed9396f2d5 (patch)
treee21dc20f55594b14d60a9fdb174393a66e32c2ac /python/samba/sd_utils.py
parentce909f2ce17e410c223a7e76cf4edc52a71aa663 (diff)
downloadsamba-1944c857e59922a2ebfc88a6a824a6ed9396f2d5.tar.gz
samba-1944c857e59922a2ebfc88a6a824a6ed9396f2d5.tar.xz
samba-1944c857e59922a2ebfc88a6a824a6ed9396f2d5.zip
s3:smb2_server: always try to grant the credits the client just consumed
It turns out that the effective credits_requested is always at least 1, even if the client sends credits_requested == 0. This means the client is not able to reduce the amount of credits itself. Without this fix a client (e.g. Windows7) would reach the case where it has been granted all credits it asked for. When copying a large file with a lot of parallel requests, all these requests have credits_requested == 0. This means the amount of granted credits where reduced by each request and only when the granted credits reached 0, the server granted one credit to allow the client to go on. The client might require more than one credit ([MS-SMB2] says Windows clients require at least 4 credits) and freezes with just 1 credit. Bug: https://bugzilla.samba.org/show_bug.cgi?id=9702 Signed-off-by: Stefan Metzmacher <metze@samba.org> Reviewed-by: Ralph Boehme <slow@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org>
Diffstat (limited to 'python/samba/sd_utils.py')
0 files changed, 0 insertions, 0 deletions