https://bugzilla.kernel.org/show_bug.cgi?id=200931 --- Comment #5 from Theodore Tso (tytso@xxxxxxx) --- The root cause of the problem is as follows. Setup: the file system has an inode, inode #16, that has a i_nlink of 1. However, there are two directory entries (with weird names for no good reason but it makes life more difficult for the bug hunter), which I will call file A and file B that both are hard links to inode #16. 1) Call chmod(File A, 3072); This brings Filename A into the dcache 2) Unlink File B. This drops the i_nlink to zero; since this means that there should be no remaining hardlinks to the file --- but i_count > 0, since we have a dcache entry for Filename A --- inode #16 is put on the orphan inode list. 3) Create a new file, call it File C. 4) Rename File C on top of File A. This causes a warning to get issued since there is an attempt to drop i_nlink to a negative value. That gets ignored so i_nlink stays at 0. But now i_count gets dropped down to 0, so the inode gets deleted and freed. But, the inode structure is still on the orphan inode list! 5) At unmount time, the fact that we still have an inode on the orphan inode list causes a warning to be printed, but it also causes the access to the freed data structure. The fix is to enforce a check that if new.inode exists, its i_nlink must be > 0. If it is 0, then something is badly wrong, and we should mark the file system as corrupted and return EFSCORRUPTED. The problem is obvious once we have the simplified poc. With the original poc, instead of 4 operations, there are 100 operations, most of which are complete red herrings. -- You are receiving this mail because: You are watching the assignee of the bug.
