[lkml]   [1997]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ext2 filesystem corruption?!?!??

Hi Ted/All,

> My patch I believe fixes the problem you found, hopefully
> without introduciig any others. (Unfortunately it appeared not to solve
> the Linux-AFS cache corruption.)

I'm not convinced your patch removes the corruption problem.
Simply locking the inode at the start of clear_inode() does not prevent
another process gaining a referernce to the inode (via __iget() or
get_empty_inode()). This is the race.
Unfortunately, clear_inode() can be called with a locked inode. To make
matters worse, clear_inode() cannot fail! It is called from fs dependent
code after the inode-dependent data has been deconstructed.

The logic behind most of the fs/inode.c code is that when a "maintainance"
operation is performed on an inode it needs locking, _and_ needs a
reference increment for that operation! This is the reason why I saw a
race in sync_inodes(). As far as I can tell, the only other operation
which does not inc the count is the call to write_inode() in

I'll try stress testing an anti-race patch, but the problem only shows up
after several hours on my test-target. Can anyone reproduce inode
corruption faster?

BTW: Does the positioning of the repeat label, in iput(), look wrong?
It's _before_ the i_count dec operation......



Mark Hemment, Unix/C Software Engineer (Contractor)
"Success has many fathers, failure is a B**TARD!" - anon

 \ /
  Last update: 2005-03-22 13:39    [W:0.090 / U:5.620 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site