On Mon, 30 Mar 2009, Kadlecsik Jozsef wrote: > 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? No, that's too simple and should have came out much earlier, the patch is from Nov 6 2008. Something like creating files in a directory by one process and statting at the same time by another one, in a loop? 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
