Slow CIFS navigation due to excessive use of QUERY_PATH_INFO

Going from kernel (x86) 2.6.27-8 (I am not sure which version of
mount.cifs) to 2.6.31-19 with mount.cifs version: 1.12-3.4.0, I
noticed an important decrease of performance while navigating CIFS
shares on a Windows 2003 server. Navigating means here either using
midnight commander, ls -l (with ls unaliased first...), rsync, etc..

I added noserverino,nolinux to the mount command, but it does not make
much difference.

The kind of performance degradation I am talking about is in the order
of times ten or so. An rsync which takes less that 2 minutes on old
hardware, now takes over 15 minutes on newer hardware!

Doing a bit of investigation with tcpdump, we can see a lot
QUERY_PATH_INFO requests happening which are not necessary as all the
information is already returned by FIND_FIRST2 requests. A trivial
example will illustrate it. Lets have a directory with 3 files inside.

ls -l with my old machine, it gives:
Protocol Info
SMB      Trans2 Request, QUERY_PATH_INFO, Query File All Info, Path: \Temp
SMB      Trans2 Response, QUERY_PATH_INFO
SMB      Trans2 Request, FIND_FIRST2, Pattern: \Temp\*
SMB      Trans2 Response, FIND_FIRST2, Files: . .. file1 file2 file3


With the new one, it gives:
Protocol Info
SMB      Trans2 Request, QUERY_PATH_INFO, Query File All Info, Path: \Temp
SMB      Trans2 Response, QUERY_PATH_INFO
SMB      Trans2 Request, FIND_FIRST2, Pattern: \Temp\*
SMB      Trans2 Response, FIND_FIRST2, Files: . .. file1 file2 file3
SMB      Trans2 Request, QUERY_PATH_INFO, Query File All Info, Path: \Temp\file1
SMB      Trans2 Response, QUERY_PATH_INFO
SMB      Trans2 Request, QUERY_PATH_INFO, Query File All Info, Path: \Temp\file2
SMB      Trans2 Response, QUERY_PATH_INFO
SMB      Trans2 Request, QUERY_PATH_INFO, Query File All Info, Path: \Temp\file3
SMB      Trans2 Response, QUERY_PATH_INFO

So for every file in the directory, as returned by the FIRST_FIND2
response, it does a QUERY_PATH_INFO, which does not bring any new
information, all the attributes were already returned by FIRST_FIND2.

That is the cause of the slowness I notice. Is that a known issue?

Thanks for your help,

Seb.