On Sun, 16 Apr 2000, Alexander Viro wrote:
> > Shouldn't there be a generic function that would find 'struct vfsmount'
> > by given 'struct super_block' and that should worry about locking/walking
> > vfsmntlist? like find_vfsmnt(sb)? Or should one keep a pointer s_vfsmnt
> > in 'struct super_block'?
>
> Not, because there is no such thing as "the vfsmount of given superblock".
> There may be many. There may be none. What are you actually trying to do?
If there are none it could return NULL but,yes, you are right about "there
may be many" - I just didn't get used yet to your idea of multiple
mounts...
Ok. what I am trying to do is to be given two inputs:
a) a process, by struct task_struct *p
b) a mounted filesystem, by struct super_block *sb
and I need to shift (forced chdir) the process to the directory covered by
the filesystem, i.e. used as a mountpoint. The filesystem in question
will be unmounted anyway so the process will be able to do lookups from
his new pwd just fine. The real function (the one I showed you was
slightly unreal :) was invoked like this:
fs_disable_pwd(task, sb->s_root);
and looks like this:
static void fs_disable_pwd(struct task_struct *p, struct dentry *root)
{
struct dentry *tmp;
tmp = p->fs->pwd;
p->fs->pwd = dget(root->d_covers);
dput(tmp);
printk(KERN_WARNING "VFS: forced chdir for %s/%d (d_count=%d)\n",
p->comm, p->pid, root->d_count);
}
(and a similar one for chroot)
so, the question is - how do your MOUNT_REWRITE changes affect it? Looking
at sys_chdir/chroot I understand that I should also switch the
p->fs->pwdmnt, shouldn't I? But sys_chdir() takes it (or will take in the
future according to your comments) from lookup_dentry().
Thanks for finding time to answer my questions.
Regards,
Tigran
PS. Actually, this thing is the part of my forced umount work and the
current state of the patch is visible from:
http://www.ocston.org/~tigran/patches/umountf.patch
(it's not finished yet as it has to deal with POSIX locks and has at least
one bug I know of - the main loop may never finish if we are unlucky - all
these will be fixed before I even think of sending this to Linus).
PPS. I know you are busy doing a lot of VFS changes, but I hope you
understand me when I am a little bit frustrated not knowing what direction
your changes are going and having to guess what it "will look like" when
they are finished.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:10 EST