From: Alexander Viro <viro@math.psu.edu>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] (part 7) fs/super.c cleanups
Date: Fri, 25 May 2001 15:23:40 -0400 (EDT) [thread overview]
Message-ID: <Pine.GSO.4.21.0105251511300.27912-100000@weyl.math.psu.edu> (raw)
Handling of refcounts for FS_SINGLE filesystems moved to
add_vfsmnt(). That's the first half of real fix for FS_SINGLE mess -
we should make it "read_super() if we hadn't done it yet, otherwise
return what we have". That will make kern_mount() uses simpler and
remove all special-casing with refcounts. in the hindsight, the trick
I've used in 2.4.0-test2 merge was ugly - kern_mount() should be used
only when kernel explicitly asks for a vfsmount of its own, not as
as part of init for FS_SINGLE filesystems. Fix is easy, but that chunk
touches several files besides fs/super.c and requires sane locking
to be safe. Patch below is the preliminary part local to fs/super.c.
Please, apply.
diff -urN S5-pre6-kern_mount/fs/super.c S5-pre6-single1/fs/super.c
--- S5-pre6-kern_mount/fs/super.c Fri May 25 15:07:19 2001
+++ S5-pre6-single1/fs/super.c Fri May 25 15:12:36 2001
@@ -367,6 +367,8 @@
list_add(&mnt->mnt_instances, &sb->s_mounts);
list_add(&mnt->mnt_list, vfsmntlist.prev);
spin_unlock(&dcache_lock);
+ if (sb->s_type->fs_flags & FS_SINGLE)
+ get_filesystem(sb->s_type);
out:
return mnt;
fail:
@@ -852,7 +854,6 @@
sb = fs_type->kern_mnt->mnt_sb;
if (!sb)
BUG();
- get_filesystem(fs_type);
do_remount_sb(sb, flags, data);
return sb;
}
@@ -1165,8 +1166,6 @@
goto out2;
err = -ENOMEM;
- if (old_nd.mnt->mnt_sb->s_type->fs_flags & FS_SINGLE)
- get_filesystem(old_nd.mnt->mnt_sb->s_type);
down(&mount_sem);
/* there we go */
@@ -1177,8 +1176,6 @@
err = 0;
up(&new_nd.dentry->d_inode->i_zombie);
up(&mount_sem);
- if (err && old_nd.mnt->mnt_sb->s_type->fs_flags & FS_SINGLE)
- put_filesystem(old_nd.mnt->mnt_sb->s_type);
out2:
path_release(&new_nd);
out1:
@@ -1369,8 +1366,6 @@
return retval;
fail:
- if (fstype->fs_flags & FS_SINGLE)
- put_filesystem(fstype);
kill_super(sb);
goto unlock_out;
}
reply other threads:[~2001-05-25 19:24 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.GSO.4.21.0105251511300.27912-100000@weyl.math.psu.edu \
--to=viro@math.psu.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).