[cifs-protocol] [MS-SMB2] Compound/async request handling, 117061615905952

[Jeremy Allison]

On Thu, Jun 29, 2017 at 09:55:03AM +0200, Moritz Bechler via cifs-protocol wrote:
> Hi,
> 
> > 
> > Just a quick note that I'm actively researching this for you.  I got a bit of a backlog with the Plugfest, but this is my primary issue now.
> Thanks.
> 
> > 
> > I'll have more research for you later as I'm presently doing a code review.  But, overall, I would be concerned not by just what a Microsoft client or Microsoft server would, could or does do, but that there is general buy-in across the board by all other non-Microsoft clients and servers.  You may be well-served by keeping all edge conditions as simple and straight-forward as possible by avoiding all but the most logical related compounding: where the file handle is inherited by the result of a create as its compound parent.  For instance, I see that the TID and SID of a related compound request is inherited by its parent request, but I'm not sure yet if its parent itself could be the TreeConnect or SessionSetup where the result of that transaction will populate down.  I'll know soon as I'm in that code; I think it will.  However, I guess what I'm saying in this message is that other servers may not have considered this type of transaction (TreeConnect/TreeTransaction) and by packing too many requests together may cause interop issues with other server implementations.
> > 
> 
> Yes, that is more or less what I concluded (e.g. the
> TreeConnect/SessionSetup compounded requests are working as one might
> expect with Microsoft servers but weren't with samba) - so they cannot
> be used generally. These are pretty easy to spot as they either always
> fail or don't. What troubles me more is async processing, because this
> is decided by the server and might depend on special conditions. The
> examples I have listed are cases specified to be processed
> asynchronously so they can also be avoided - but following the logic I
> see in product behavior for these something as simple as
> 
> CREATE/READ/CLOSE (or WRITE,IOCTL,QUERY_INFO,... instead of the READ)
> 
> might suddenly fail if the server decided to go async for the READ (say,
> that it might choose async when the backend read hits some time limit)
> and they are not handled like a CREATE is. These would probably be
> considered server bugs if they failed as they are likely to be actually
> used by clients. Right now it seems like it is up to the client to guess
> which requests are handled in which way (whether they can go async and
> whether they will fail if they are not last in a chain).

No, I don't think they're server bugs. The client must cope with
compound requests going async and re-submit I think.