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

[Ira Cooper]

You'll find it easy to reproduce if you:

Set  aio read size = 1 in smb.conf.

And modify line 101 in smb2_read.c or close by to be:

    return smbd_smb2_request_pending_queue(req, subreq, 1);

Writing a 1 GB file, umounting the share, and mounting the share again,
then using dd to read it back with rsize and wsize set to 1MB, should do it.

We can reproduce it as is with Gluster, I suspect that may be enough to do
it with XFS or other filesystems.

Does anyone know what the windows timeout for sending the interim reply
is?  Barring this bug, sending it when we don't have to is wasteful.

Thanks,

-Ira

On Tue, Feb 23, 2016 at 11:11 PM, Steven French <sfrench at samba.org> wrote:

> Do we have a reproduction scenario?  I don’t remember this one and it
> doesn’t send familiar at all - I use smb3 kernel client to Samba every day.
>
> And yes - if we have a bug in the kernel client here let’s fix it.
>
>
>
> On Feb 23, 2016, at 7:05 AM, Stefan Metzmacher <metze at samba.org> wrote:
>
> Hi Ira,
>
> 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.
>
>
> Fix the broken kernel client!
>
> I think this is nothing we should work around in the server.
> The situation might be different if Windows clients would be unhappy,
> but the linux client is more or less under our control and can be fixed.
>
> People hitting this can just use SMB1 until it's fixed.
>
> metze
>
>
>