Bug #14739
open
smbtorture disconnect after bad credit grant
0%
Description
Running smbtorture tests on a small VM with reduced max_credits (16) I saw many failures that were not in my "baseline" results (with default max_credits). The failures involve credit grants in async responses, where the server returns "status pending" to the client in an interim response, later followed by the final response for the request. An example failure is smb2.lock.async
as shown in the attached capture: lock-async-1.snoop where in frame 30, we've returned a credit grant of 0xFFF2, and then the client disconnected.
Files
Updated by Gordon Ross 24 days ago
- Status changed from New to In Progress
There's an underflow in the calculation of new credits here:
usr/src/uts/common/fs/smbsrv/smb2_dispatch.c around 392
in smb2_credit_increase()
/*
* If new credits would be above max,
* reduce the credit grant.
*/
if (cur > session->s_max_credits) {
d = cur - session->s_max_credits;
cur = session->s_max_credits;
sr->smb2_credit_response -= d; // << underflow!
DTRACE_PROBE1(smb2__credit__max, smb_request_t, sr);
}
This seems to be only exposed when the session s_max_credits is clamped down,
but there is also a logic bug where we've failed to set the smb2_credit_response
in the earlier smb2_credit_decrease().
Updated by
Updated by Gordon Ross 24 days ago
- Description updated (diff)
- Gerrit CR deleted (
2183)
Updated by Gordon Ross 24 days ago
Before fix:
$ smbtorture -U ... //server/share smb2.lock.async ... test: async ... failure: async [ ../../source4/torture/smb2/lock.c:849: status was NT_STATUS_INVALID_NETWORK_RESPONSE, expected NT_STATUS_OK: (../../source4/torture/smb2/lock.c:849) ]
after the fix, no errors
$ smbtorture -U ... //server/share smb2.lock.async ... test: async ... success: async