[jcifs] Deadlock in SmbTransport

[Konrad Kamiński]

Hi!

I found a similar problem to the one which had been discussed in December (Thread: Deadlock in Java code http://lists.samba.org/pipermail/jcifs/2002-December/001574.html). The problem is that in SmbTransport.tryClose () method there's a loop over all of the sessions (SmbSession) associated with this SmbTransport. This method however can be called from

SmbTree.treeConnect (locks SmbTree AND SmbSession)
|---- SmbSession.send
       |------------- SmbSession.sessionSetup (locks SmbSession again)
                        |------------------ SmbTransport.send
                                               |----------------- SmbTransport.tryClose ()

So if say there's a SmbTree.treeConnect called from SmbSession_1 and concurrently from SmbSession_2, and if both SmbSession's are associated with the same SmbTransport, then if for any reason (eg. DC connection timeout) both will call SmbTransport.tryClose() then there's a deadlock :

THREAD_1 : time(0) : SmbSession_1 (LOCK SmbSession_1) 
THREAD_2 : time(1) : SmbSession_2 (LOCK SmbSession_2)
THREAD_1 : time(2) : SmbTransport.tryClose - iterates over SmbSession and tries to do SmbSession2.logoff (synchronized and LOCKS -> wait)
THREAD_2 : time(3) : SmbTransport.tryClose - iterates over SmbSession and tries to do SmbSession1.logoff (synchronized and LOCKS -> wait forever -> DEADLOCK)

The simplest solution would be to do a some sort of synchronization before calling the SmbTree.treeConnect method, but that would make it very inefficient (if you need to call treeConnect very often - that's the situation in our project). Do you know of any other solution? BTW I think this is also a bug.

Regards, Konrad Kaminski
-------------- next part --------------
HTML attachment scrubbed and removed