[linux-cifs-client] client deadlock (rename and readdir)

[Alan Tyson]

Hi,

I've been doing further testing using some stress tests that I mentioned 
in the "oops" posting last week and, as I mentioned, I've seen some 
client hangs when running two instances of the tests on the same client.

I've been using FC5 (2.6.15-1.2054_FC5smp) and the 1.42 version of the 
cifs client that I downloaded from 
http://pserver.samba.org/samba/ftp/cifs-cvs/

The scripts hung about 1-2 mins into the test.  Here are the stack 
traces of the two hung processes:

crash> bt 17223
PID: 17223  TASK: c17e09d0  CPU: 3   COMMAND: "mv"
 #0 [c9a65e38] schedule at c02f0d3d
 #1 [c9a65ea8] __mutex_lock_slowpath at c02f1ab9
 #2 [c9a65ec4] .text.lock.mutex (via mutex_lock) at c02f1afa
 #3 [c9a65ed0] lock_rename at c016d8fd
 #4 [c9a65ee0] sys_renameat at c016fe7e
 #5 [c9a65fa4] sys_rename at c016ff77
 #6 [c9a65fb8] system_call at c0103d7a

crash> bt 17224
PID: 17224  TASK: dd5c6b70  CPU: 2   COMMAND: "find"
 #0 [dbdc5da0] schedule at c02f0d3d
 #1 [dbdc5e10] __down at c02f2175
 #2 [dbdc5e58] __sched_text_start at c02f022a
 #3 [dbdc5e64] .text.lock.readdir (via initiate_cifs_search) at e0bece1b
 #4 [dbdc5e84] cifs_readdir at e0bebd18
 #5 [dbdc5f78] vfs_readdir at c0171c50
 #6 [dbdc5f94] sys_getdents64 at c0171cdb
 #7 [dbdc5fb8] system_call at c0103d7a

pid 17223 (mv) is renaming the file /CIFS1/test1/in/fileV17165 to 
/CIFS1/test1/work/fileV17165 .  From the code of lock_rename is it clear 
that it has locked the superblock rename semaphore and is currently 
waiting on the mutex for inode /CIFS1/test1/in .

pid 17224 (find) is doing a readdir of /CIFS1/test1/in and is waiting on 
the superblock rename semaphore.  It locked the mutex of the inode in 
vfs_readdir.

I can post more detailed findings if anyone would like to see more.

Regards,

Alan Tyson,
Global Solutions Engineering,
Hewlett-Packard.