Interop Issue: SMB2+ async replies, and the kernel, Samba side fix enclosed.

[Christian Ambach]

Am 01.03.16 um 14:40 schrieb Volker Lendecke:
> On Wed, Feb 24, 2016 at 11:04:08AM -0800, Jeremy Allison wrote:
>> Hmmm. We can only test this by causing a Windows read to
>> take a long time. Any idea how to test this ? Does Win32
>> have named pipes in the fs we could use for that ? If not
>> we could test using a program that creates a \\pipe\named_pipe
>> and then responds slowly... But I don't know if the
>> timeout replies on np's are the same as in the filesystem.
>
> Just use a USB2 stick.
>
[MS-SMB2] gives some hints when Windows will send out interim replies:
<296> Section 3.3.5.12: Windows SMB2 servers send an interim response to 
the client and handle the read asynchronously if the read is not 
finished in 0.5 milliseconds.
<297> Section 3.3.5.12: Windows-based servers handle the following
commands asynchronously: SMB2 Create (section 2.2.13) when this create would
result in an oplock break, SMB2 IOCTL Request (section 2.2.31) for
FSCTL_PIPE_TRANSCEIVE if it blocks for more than 1 millisecond, SMB2 IOCTL
Request for FSCTL_SRV_COPYCHUNK or FSCTL_SRV_COPYCHUNK_WRITE (section 
2.2.31)
when oplock break happens, SMB2 Change_Notify Request (section 2.2.35) if
it blocks for more than 0.5 milliseconds, SMB2 Read request (section 2.2.19)
for named pipes if it blocks for more than 0.5 milliseconds,
SMB2 Write request (section 2.2.21) for named pipes if it blocks for more
than 0.5 milliseconds, SMB2 Write Request (section 2.2.21) for large 
file write,
SMB2 lock request (section 2.2.26) if the LOCKFLAG_FAIL_IMMEDIATELY flag 
is not set,
and SMB2 FLUSH Request (section 2.2.17) for named pipes.

Cheers,
Christian