Hi, On Sun, 29 Mar 2009, Wendy Cheng wrote: > Kadlecsik Jozsef wrote: > > There are three different netconsole log recordings at > > http://www.kfki.hu/~kadlec/gfs/ > One of the new console logs has a good catch (netconsole0.txt): you *do* have > a deadlock as the CPUs are spinning waiting for spin lock. This seems to be > more to do with the changes made via bugzilla 466645. I think RHEL version > that has the subject patch will have the same issue as well. You mean the part of the patch @@ -1503,6 +1503,15 @@ gfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct error = gfs_glock_nq_init(ip->i_gl, LM_ST_SHARED, LM_FLAG_ANY, &gh); if (!error) { generic_fillattr(inode, stat); + if (S_ISREG(inode->i_mode) && dentry->d_parent + && dentry->d_parent->d_inode) { + p_inode = igrab(dentry->d_parent->d_inode); + if (p_inode) { + pi = get_v2ip(p_inode); + pi->i_dir_stats++; + iput(p_inode); + } + } gfs_glock_dq_uninit(&gh); } might cause a deadlock: if the parent directory inode is already locked, then this part will wait infinitely to get the lock, isn't it? If I open a directory and then stat a file in it, is that enough to trigger the deadlock? [Shouldn't we move this thread to the cluster-devel list?] Best regards, Jozsef -- E-mail : kadlec@xxxxxxxxxxxx, kadlec@xxxxxxxxxxxxxxxxx PGP key: http://www.kfki.hu/~kadlec/pgp_public_key.txt Address: KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
