On Mon, 24 Feb 2003, Szakacsits Szabolcs wrote: > On Sun, 23 Feb 2003, Anton Altaparmakov wrote: > Yes, thanks for everybody who responded, excellent feedbacks! It's > 100% posible to reproduce the hang even with standard 2.4.20+ kernels.
Indeed. I was able to reproduce with 2.4.21-pre4 + NTFS 2.1.0a and 2.1.1a. Interestingly the hangs cannot be reproduced on 2.5.x kernels which suggests that either 2.4 is holding the inode lock somewhere where 2.5 isn't so when we try to acquire it we hang because the kernel already acquired it or the iget4 race avoidance I had to patch up into 2.4 causes the hangs. > > It points me directly at the code responsible for the hangs. The > > above should hopefully allow me to reproduce the hang and fix the > > problem. Most likely it is something to do with the dcache code in > > fs/ntfs/namei.c::ntfs_lookup() that handles the case insensitive > > file and directory names in NTFS. This is supported by the > > reported trace from the kernel showing that the code hangs inside > > ntfs_lookup() when the inode lock is attempted to be acquired. > > The inode locking, needed to close iget4 race, looks totally broken. Hmm. That is one of my two prime suspects. /me goes and looks... Eeeeeeeeeeeeeeeeeeeeeek!!! Grrrrrrrrrrrrrrrrrrrrrrr!!! /me slaps myself with a wet fish... /me corrects logic inversion in ntfs inode lock handling... /me recompiles module and tests... It works! (-: I will commit the patch to the BK ntfs-2.4 repository in a few minutes and then make an incremental patch to ntfs 2.1.0a patch... Best regards, Anton -- Anton Altaparmakov <aia21 at cantab.net> (replace at with @) Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/