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

[Ira Cooper]

If the server sends an interim response, then the real response, the real
response, is handled by standard_receive3() in the kernel, instead of the
proper function, and this causes a disconnect.  If there isn't a
disconnect, I believe the reply will just be discarded if I understand the
code correctly.  (That is a big if here ;) )

I've written a patch for Samba to stop sending interim replies on SMB2_READ
and SMB2_WRITE, when non-compounded to stop the impact of this issue.  We
may want to add SMB2_CREATE to the list of ops we don't send async replies
for non-compounded, but I'm not sold either way, I know we CAN go async
there!  I want some opinions here.

This is not hidden behind a flag because compatibility issues that don't
impact protocol correctness usually aren't.

Setting req->async_te = talloc_new(NULL); is just ugly, though it works.
If you have a cleaner approach, I welcome it.

I request you please ASK me before pushing this one, yes, that means you
jra!

For those interested in reproduction: I'd suggest using a server that's
rebuilt with a lower timeout set in smb2_read.c, though we've hit it with
vfs_glusterfs straight up, in our testing.

Thanks,

-Ira / ira@(samba.org|redhat.com|wakeful.net)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-smbd-Work-around-for-AIO-with-the-Linux-CIFS-client-.patch
Type: application/mbox
Size: 1808 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20160223/628ab967/0001-smbd-Work-around-for-AIO-with-the-Linux-CIFS-client-.mbox>