There are three patches at
http://www.zip.com.au/~akpm/linux/patches/2.4/2.4.20/
sync_fs.patch:
Fix the ext3 data=journal data-loss-on-unmount bug
sync_fs-fix.patch:
Fix sync_fs.patch to not deadlock the fs when running
`mount -o remount' against a heavily loaded filesystem.
ext3-use-after-free.patch
Fix a use-after-free bug which can cause memory corruption
if the filesystem runs out of space, or runs out of free
inodes.
Instructions for downloading and applying these patches are at
http://www.zip.com.au/~akpm/linux/ext3/
Hmmm, this took me a while to find the first time around in the
commit_super code, and I almost forgot about it.
Looking at the loop in sync_supers()
while (sb != sb_entry(&super_blocks))
if (sb->s_dirt) {
sb->s_count++;
spin_unlock(&sb_lock);
Right here, we can race against kill_super, which means an unmount can
make the FS go away completely. The only thing that saves the
write_super() call is a check for s->s_root != NULL. Since we don't
check that before calling sync_fs, it should race against an unmount.
down_read(&sb->s_umount);
write_super(sb);
if (wait && sb->s_op && sb->s_op->sync_fs)
sb->s_op->sync_fs(sb);
drop_super(sb);
goto restart;
} else
Any reason ext3 can't have a check for s_root in there?
-chris