On Sat, 24 Mar 2001, Jorgen Cederlof wrote:
> > kill_super() releases the reference stored in ->s_type (created
> > by get_sb_...()). If superblock stays alive you should not release it.
>
> get_sb_...() will do get_filesystem() even if superblock stays alive.
Sigh... I see what happens, and yes, it's a bug, but fix is wrong.
The real problem is with get_sb_single(), not with do_mount().
get_sb_bdev() and get_sb_nodev() are actually fine and your fix will
break them.
The problem is in the way we keep count for FS_SINGLE - in my current
tree I switched to cleaner variant, but doing the same in 2.4 may be tricky.
_Probably_ the right way to deal with that (for the time being) is add
if (fstype->fs_flags & FS_SINGLE)
put_filesystem(fstype);
before the if (list_empty(...))
IOW,
--- fs/super.c.old Sat Mar 24 12:39:23 2001
+++ fs/super.c Sat Mar 24 12:39:56 2001
@@ -1412,6 +1412,8 @@
return retval;
fail:
+ if (fstype->fs_flags & FS_SINGLE)
+ put_filesystem(fstype);
if (list_empty(&sb->s_mounts))
kill_super(sb, 0);
goto unlock_out;
should be OK for now. Once we get clean refcounting for struct super_block
we will be able to get rid of the kludges in that area completely.
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
