[linux-cifs-client] OOPS (then hang) in cifs client during rename

[Alan Tyson]

Hi,

I have been working with one of our customers who is planning on using 
cifs clients in their network.  As part of their stress testing, they 
have hit a problem in the cifs module when multiple clients are moving 
files from one directory on the server to another one.  Both directories 
are under the same mount point and the problem (sometimes) happens when 
two clients try to perform the same move at the same time (not a 
particularly smart thing to do, but serves it's purpose here).

The symptoms of the problem are an OOPS caused by an attempt at a null 
pointer dereference followed by client hangs.

Our customer is using SLES9 SP3 which has the 1.33 version of the cifs 
client.  I can also duplicate the problem using Fedora Core 5 which has 
the 1.40 version of the client and, whilst I've not specifically tested 
it, I feel that the problem is still there in the latest version.

I believe that I have identifed the root cause of the problem.  I'm not 
too sure about the ettiqiette of what I should post here and what I 
should put into a bugzilla describing what I've found, so some guidance 
in this area would be appreciated.

For the curious, the oops is (trying to keep it brief):
Unable to handle kernel NULL pointer dereference at virtual address 0000002c

crash> bt
PID: 15948  TASK: dee72000  CPU: 1   COMMAND: "mv"
 #0 [d92d7cb0] schedule at c012642a
 #1 [d92d7d38] SendReceive at e0d4ab8c
 #2 [d92d7da8] error_code at c010a27b
    EAX: 00000000  EBX: d9ec13c0  ECX: df6da638  EDX: d97f0b80  EBP: 
0002073a
    DS:  007b      ESI: d9265968  ES:  007b      EDI: 00000000
    CS:  0060      EIP: e0d3a7c3  ERR: ffffffff  EFLAGS: 00010246
 #3 [d92d7de4] cifs_unlink at e0d3a7c3
 #4 [d92d7e44] cifs_rename at e0d3acf7
 #5 [d92d7ea0] vfs_rename_other at c0183821
 #6 [d92d7ec0] vfs_rename at c0184ca2
 #7 [d92d7edc] sys_rename at c0186e91
 #8 [d92d7fc0] sysenter_entry at c01091d2

and I believe that the fix would be to make the call to cifs_unlink from 
cifs_rename conditional upon dentry->d_inode being not NULL, but can 
post more information here or in a bugzilla, as you suggest.

Many thanks,

Alan Tyson,
Global Solutions Engineering,
Hewlett Packard.