On 2012/09/26 18:09, Jan Kara wrote:
I should have explained my fears better. If no one else
is holding an active reference we will end up executing:
fs->kill_sb(s);
...
put_filesystem(fs);
put_super(s);
in deactivate_locked_super(). If s_count is greater than 0
the superblock will not be freed, as you say, however we
still do "fs->kill_sb(s)" and "put_filesystem(fs)" and I am not
sure whether this is safe when MS_BORN flag is not set in
the superblock. I will check how MS_BORN is being used
once more and try to figure it out (if you are familiar with
MS_BORN I would appreciate it your advise).
I see. Well, from a brief check I don't think we should ever get to a
superblock without MS_BORN set. All functions iterating over superblocks
return only superblocks with MS_BORN set. In particular freeze_bdev() even
has an active reference itself and ioctl_fsfreeze() has a file open on the
sb which guarantees an active reference as well...
As you say when we get there via the superblock level API
it is guaranteed that we have at least one active reference
and that MS_BORN is set. However, freeze_bdev() iterates
over superblocks using get_active_super() which can return
a superblock without the MS_BORN flag set; during sys_mount
mount_fs() sets the MS_BORN flag *after* sget() inserts the
superblock in all the lists.
If the analysis above is correct we do need the MS_BORN
check.
By the way, tomorrow I will be sending v5 of this patch set.
Thanks,
Fernando
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
