Messages in this thread | | | Subject | Re: [2.4] VFS locking problem during concurrent link/unlink | From | Chris Mason <> | Date | 16 Jan 2003 11:02:08 -0500 |
| |
On Thu, 2003-01-16 at 10:43, Oleg Drokin wrote: > Hello! > > On Thu, Jan 16, 2003 at 10:39:41AM -0500, Chris Mason wrote: > > > Debugging reiserfs problem that can be demonstrated with script created by > > > Zygo Blaxell, I started to wonder if the problem presented is indeed reiserfs > > > fault and not VFS. > > > Though the Zygo claims script only produces problems on reiserfs, I am trying > > > it now myself on ext2 (which will take some time). > > > > > > Debugging shows that reiserfs_link is sometimes called for inodes whose > > > i_nlink is zero (and all corresponding data is deleted already). > > > So my current guess of what's going on is this: > > No, this is a reiserfs bug, since we schedule after doing link checks in > > reiserfs_link and reiserfs_unlink. I sent a patch to reiserfs dev a > > while ago, I'll pull it out of the suse kernel and rediff against > > 2.4.20. > > Yes we do. > But on the other hand I've put a check at the beginning of reiserfs_link > and I am still seeing these links on inodes with i_nlink == 0.
That's because we don't inc the link count in reiserfs_link before we schedule. The bug works a little like this:
link count at 1 reiserfs_link: make new directory entry for link, schedule() reiserfs_unlink: dec link count to zero, remove file stat data reiserfs_link: inc link count, return thinking the stat data is still there
All of which leads to expanding chaos as we process this link pointing to nowhere but still have a valid in ram inode pointing to it.
-chris
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |