Bug 3983 - Multiple trans2 responses not handled correctly.
Summary: Multiple trans2 responses not handled correctly.
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: All Windows XP
: P3 normal (vote)
Target Milestone: ---
Assignee: Stefan Metzmacher
QA Contact: Andrew Bartlett
Depends on:
Reported: 2006-08-01 20:18 UTC by Murali Bashyam
Modified: 2008-08-14 13:01 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Murali Bashyam 2006-08-01 20:18:31 UTC
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.
Comment 1 Matthias Dieter Wallnöfer 2007-11-27 14:06:42 UTC
What is with this bug?
Comment 2 Andrew Bartlett 2008-01-07 00:56:13 UTC
Should the CIFS client be set to serialize at all?

Tridge:  Can you enlighten us on this situation, and it's history?
Comment 3 Matthias Dieter Wallnöfer 2008-08-14 11:27:54 UTC
Is this issue still valid? Please answer, otherwise I'll close this due to lack of participation (since 2006).
Comment 4 Stefan Metzmacher 2008-08-14 13:01:31 UTC
Should be fixed with commit ec67c61b6a82e4f39a15f37a98ae3fe93bb81316