On samba4 TP2, i am noticing the following problem when there are multiple trans2 responses to a single trans2 request.

After processing the first response, smb_raw_trans2_recv calls smbcli_request_receive_more to handle the next response message, and ends up blocking in epoll_wait waiting for a read event. Some time later when the next trans2 response message is received, the wait unblocks, and then ends up calling packet_receive (via smbcli_transport_event_handler). packet_recv checks for the 'processing' flag in the packet context, and since this flag is still set, it simply marks the fde not readable and returns without picking up the next message, ultimately leading to a timeout. The 'processing' flag in the packet context is not reset until we return from smb_raw_trans2_recv back to the smbcli_transport_finish_recv function. This seems to be leading to a deadlock in the multiple trans2 response scenario where the smb client raw layer thinks there is no message pending for it even though there is one and it is ready to process it, and the packet layer is serializing the next response waiting for the smb client raw layer to indicate to the packet layer somehow that it's finished with the previous response.