Remount read-only races?

Hello,

Toshiyuki reported an ext3 error message which implies that we can have
unlinked but open files on read-only filesystem. Apparently open+unlink races with remount in some way. Looking at code in do_remount_sb() I don't see what prevents open("file", O_WRONLY) to happen after the check fs_may_remount_ro() and before the filesystem is marked as read-only. So are we expected to prevent these races? If yes, do I just miss something or the above race is really there? Thanks for reply in advance.

Honza

Jan Kara <[email protected]>
SUSE Labs, CR

remount r/o is completely racy. It only updates the superblock to r/o state once ->remount_fs has returned. So you can easily open new files after the check for r/w files, or in the middle of remount_fs.

We have an assert that we had to tone down to an WARN_ON in xfs that can be triggered fairly easily due to this. The fix is to have some sort of transient r/o state before calling into ->remount_fs. I've been thinking about it for a while, and one thing I considered was to freeze the fs when entering do_remount_sb, and then operate on a frozen fs. This sounds easier than it is as all remount_fs instances need to know about it to not deadlock against the frozen fs checks.

Yes, that race is there. I have a patchset to fix most of the races:

https://lkml.org/lkml/2011/1/18/94

I'll update it to the current kernel.

There's still one race that it doesn't fix, if the inode still has a stray reference not obtained from open() after nlink has gone to zero. This can be fixed by adding a counter similar to mnt_writers to the superblock and incrementing it in drop_nlink().

Thanks,
Miklos