Re: How to query mount propagation state?
On Mon, 2007-04-16 at 23:07 +0200, Karel Zak wrote: > On Mon, Apr 16, 2007 at 10:39:46AM -0700, Ram Pai wrote: > > > This patch disambiguates multiple mount-instances of the same > > filesystem (or part of the same filesystem), by introducing a new > > interface /proc/mounts_new. The interface has the following format. > ^^ > ... odd name. What will be the name for a next generation? > "/proc/mounts_new_new"? :-) > that was the name I came up with 6 months back :-). Yes It should be something more appropriate. Maybe /proc/mounts_1 ? The next generation one would be /proc/mounts_2 ? Suggestion? > > 'cat /proc/mounts' shows the following: > > /dev/root /mnt ext2 rw 0 0 > > /dev/root /tmp1 ext2 rw 0 0 > > > > NOTE: The above mount entries, do not indicate that /tmp1 contains the same > > directory tree as /var/tmp. > > > > But 'cat /proc/mounts_new' shows us the following: > > 0x6200 /mnt /var ext2 rw 0 0 > > 0x6200 /tmp1 /var/tmp ext2 rw 0 0 > > Can't you purely and simply add the fsid= option to /proc/mounts? > > /dev/root /mnt ext2 rw,fsid=0x6200 0 0 > /dev/root /mnt ext2 rw,fsid=0x6200 0 0 > > I think you can do it without a negative impact to userspace. ok. > > > This patch introduces a new proc interface that exposes all the propagation > > trees within the namespace. > > Good idea. > > > It walks through each off the mounts in the namespace, and prints the > > following information. > > > > mount-id: a unique mount identifier > > dev-id : the unique device used to identify the device containing the > > filesystem > > Why not major:minor? Thinking about it, I feel we dont need this field at all. Basically we need a field that can be keyed-upon to find the corresponding record in /proc/mounts_1. mount-id can be used as the matching field, provided we add the mount-id field to /proc/mounts_1. agree? RP > > path-from-root: mount point of the mount from / > > path-from-root-of-its-sb: path from its own root dentry. > > propagation-flag: SHARED, SLAVE, UNBINDABLE, PRIVATE > > peer-mount-id: the mount-id of its peer mount (if this mount is shared) > > master-mount-id: the mount-id of its master mount (if this mount is slave) > > > Example: > > Here is a sample output of cat /proc/$$/mounts_propagation > > > > 0xa917800 0x1 / / PRIVATE > > 0xa917200 0x6200 / / PRIVATE > > 0xa917180 0x3 /proc / PRIVATE > > 0xa917f80 0xa /dev/pts / PRIVATE > > 0xa917100 0x6210 /mnt / SHARED peer:0xa917100 > > 0xa917f00 0x6210 /tmp /1 SLAVE master:0xa917100 > > 0xa917900 0x6220 /mnt/2 / SHARED peer:0xa917900 > > Same thing (although the mounts_propagation makes more sense than > mount_new from my point of view). > > cat /proc/mounts (or /proc/$$/mounts) > > /dev/root /mnt ext2 rw,mid=0xa917100,did=0x6210,prop=SHARED,peer=0xa917100 > > > my $0.02... > > Karel > - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to query mount propagation state?
On Mon, 2007-04-16 at 14:16 -0500, Serge E. Hallyn wrote:
> > This patch introduces a new proc interface that exposes all the
> propagation
> > trees within the namespace.
> >
> > It walks through each off the mounts in the namespace, and prints
> the following information.
> >
> > mount-id: a unique mount identifier
> > dev-id : the unique device used to identify the device containing
> the filesystem
> > path-from-root: mount point of the mount from /
> > path-from-root-of-its-sb: path from its own root dentry.
> > propagation-flag: SHARED, SLAVE, UNBINDABLE, PRIVATE
> > peer-mount-id: the mount-id of its peer mount (if this mount is
> shared)
> > master-mount-id: the mount-id of its master mount (if this mount is
> slave)
> >
> > Using the above information one could easily write a script that can
> > draw all the propagation trees in the namespace.
> >
> >
> > Example:
> > Here is a sample output of cat /proc/$$/mounts_propagation
> >
> > 0xa917800 0x1 / / PRIVATE
> > 0xa917200 0x6200 / / PRIVATE
> > 0xa917180 0x3 /proc / PRIVATE
> > 0xa917f80 0xa /dev/pts / PRIVATE
> > 0xa917100 0x6210 /mnt / SHARED peer:0xa917100
> > 0xa917f00 0x6210 /tmp /1 SLAVE master:0xa917100
> > 0xa917900 0x6220 /mnt/2 / SHARED peer:0xa917900
> >
> > line 5 indicates that the mount with id 0xa917100 is mounted at /mnt
> is shared
> > and it is the only mount in its peer group.
> >
> > line 6 indicates that the mount with id 0xa917f00 is mounted
> at /tmp, its
> > root is the dentry 1 present under its root directory. This mount is
> a
> > slave mount and its master is the mount with id 0xa917100.
> >
> > line 7 indicates that the mount with id 0xa917900 is mounted
> at /mnt/2, its
> > root is the dentry / of its filesystem. This mount is a
> > shared and it is the only mount in its peer group.
> >
> > one could write a script which runs through these lines and draws 4
> > individual satellite mounts and two propagation trees, the first
> propagation
> > tree has a shared mount and a slave mount. and the second
> propagation tree has
> > just one shared mount.
> >
> >
> > Signed-off-by: Ram Pai <[EMAIL PROTECTED]>
> > ---
> > fs/namespace.c | 42 ++
> > fs/pnode.c |6 --
> > fs/pnode.h |6 ++
> > fs/proc/base.c | 22 +-
> > 4 files changed, 69 insertions(+), 7 deletions(-)
> >
> > Index: linux-2.6.17.10/fs/namespace.c
> > ===
> > --- linux-2.6.17.10.orig/fs/namespace.c
> > +++ linux-2.6.17.10/fs/namespace.c
> > @@ -410,6 +410,41 @@ static int show_vfsmnt_new(struct seq_fi
> > return show_options(m, v);
> > }
> >
> > +static int show_vfsmnt_propagation(struct seq_file *m, void *v)
> > +{
> > + struct vfsmount *mnt = v;
> > + seq_printf(m, "0x%x", (int)mnt);
> > + seq_putc(m, ' ');
> > + seq_printf(m, "0x%x", new_encode_dev(mnt->mnt_sb->s_dev));
> > + seq_putc(m, ' ');
> > + seq_path(m, mnt, mnt->mnt_root, " \t\n\\");
> > + seq_putc(m, ' ');
> > + seq_dentry(m, mnt->mnt_root, " \t\n\\");
> > + seq_putc(m, ' ');
> > +
> > + if (IS_MNT_SHARED(mnt)) {
> > + seq_printf(m, "%s ", "SHARED");
> > + if (IS_MNT_SLAVE(mnt)) {
> > + seq_printf(m, "%s ", "SLAVE");
> > + }
> > + } else if (IS_MNT_SLAVE(mnt)) {
> > + seq_printf(m, "%s ", "SLAVE");
> > + } else if (IS_MNT_UNBINDABLE(mnt)) {
> > + seq_printf(m, "%s ", "UNBINDABLE");
> > + } else {
> > + seq_printf(m, "%s ", "PRIVATE");
> > + }
> > +
> > + if (IS_MNT_SHARED(mnt)) {
> > + seq_printf(m, "peer:0x%x ", (int)next_peer(mnt));
>
> Ok, so if the sequence of events was
>
> mount --make-shared /mnt
> (some user logs in and gets a cloned namespace, so his /mnt
> becomes the next peer of /mnt)
> mount --bind /mnt /tmp
> (some other user logs in and gets cloned namespace...)
>
> or some such sequence of events, we could lose all information
> about /mnt and /tmp being peers, right? Should a new
> next_peer_in_same_namespace(mnt) be used rather than next_peer()?
you are right. it should print next_peer(mnt) only if CAP_SYS_ADMIN,
else print next_peer_in_same_namespace(mnt).
>
> Somewhat similarly,
>
> > + }
> > + if (IS_MNT_SLAVE(mnt)) {
> > + seq_printf(m, "master:0x%x ", (int)mnt->mnt_master);
>
> Should we for privacy reasons not print out the address
> mnt->mnt_master
> is in a different namespace (perhaps if !CAP_SYS_ADMIN)?
right. it should print mnt->mnt_master if (CAP_SYS_ADMIN), otherwise
print master_in_same_namespace(mnt).
RP
>
> Otherwise I like this.
>
> thanks,
> -serge
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to query mount propagation state?
On Mon, Apr 16, 2007 at 10:39:46AM -0700, Ram Pai wrote: > This patch disambiguates multiple mount-instances of the same > filesystem (or part of the same filesystem), by introducing a new > interface /proc/mounts_new. The interface has the following format. ^^ ... odd name. What will be the name for a next generation? "/proc/mounts_new_new"? :-) > 'cat /proc/mounts' shows the following: > /dev/root /mnt ext2 rw 0 0 > /dev/root /tmp1 ext2 rw 0 0 > > NOTE: The above mount entries, do not indicate that /tmp1 contains the same > directory tree as /var/tmp. > > But 'cat /proc/mounts_new' shows us the following: > 0x6200 /mnt /var ext2 rw 0 0 > 0x6200 /tmp1 /var/tmp ext2 rw 0 0 Can't you purely and simply add the fsid= option to /proc/mounts? /dev/root /mnt ext2 rw,fsid=0x6200 0 0 /dev/root /mnt ext2 rw,fsid=0x6200 0 0 I think you can do it without a negative impact to userspace. > This patch introduces a new proc interface that exposes all the propagation > trees within the namespace. Good idea. > It walks through each off the mounts in the namespace, and prints the > following information. > > mount-id: a unique mount identifier > dev-id : the unique device used to identify the device containing the > filesystem Why not major:minor? > path-from-root: mount point of the mount from / > path-from-root-of-its-sb: path from its own root dentry. > propagation-flag: SHARED, SLAVE, UNBINDABLE, PRIVATE > peer-mount-id: the mount-id of its peer mount (if this mount is shared) > master-mount-id: the mount-id of its master mount (if this mount is slave) > Example: > Here is a sample output of cat /proc/$$/mounts_propagation > > 0xa917800 0x1 / / PRIVATE > 0xa917200 0x6200 / / PRIVATE > 0xa917180 0x3 /proc / PRIVATE > 0xa917f80 0xa /dev/pts / PRIVATE > 0xa917100 0x6210 /mnt / SHARED peer:0xa917100 > 0xa917f00 0x6210 /tmp /1 SLAVE master:0xa917100 > 0xa917900 0x6220 /mnt/2 / SHARED peer:0xa917900 Same thing (although the mounts_propagation makes more sense than mount_new from my point of view). cat /proc/mounts (or /proc/$$/mounts) /dev/root /mnt ext2 rw,mid=0xa917100,did=0x6210,prop=SHARED,peer=0xa917100 my $0.02... Karel -- Karel Zak <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to query mount propagation state?
Quoting Ram Pai ([EMAIL PROTECTED]):
> On Mon, 2007-04-16 at 12:34 +0200, Miklos Szeredi wrote:
> > Currently one of the difficulties with mount propagations is that
> > there's no way to know the current state of the propagation tree.
> >
> > Has anyone thought about how this info could be queried from
> > userspace?
>
> I am attaching two patches that I had done way back in Oct 2006
> with Al Viro. I had sent these patches to Al Viro. But I forgot to
> follow them up, I guess so did Al Viro.
>
> The first patch disambiguates multiple mount-instances of the same
> filesystem (or part of the same filesystem), by introducing a new
> interface /proc/mounts_new.
>
> The second patch introduces a new proc interface that exposes all the
> propagation trees within a namespace. It does not show propagated
> mounts residing in a different namespace (for privacy reasons). Maybe
> one could modify the patch a little, to allow it; if the user has
> root priviledges.
>
> RP
>
> PS: Sorry these are attachments instead of inline patches. I am scared
> of inlining in evolution. If needed I can send inline patches through
> mutt.
>
> >
> > Thanks,
> > Miklos
> This patch disambiguates multiple mount-instances of the same
> filesystem (or part of the same filesystem), by introducing a new
> interface /proc/mounts_new. The interface has the following format.
>
>
> FSID mntpt root-dentry fstype fs-options
>
>
> NOTE: root-dentry is the path to the dentry w.r.t to the root dentry of the
> same filesystem.
>
> for example: lets say we attempt the following commands
> mount --bind /var /mnt
> mount --bind /mnt/tmp /tmp1
>
> 'cat /proc/mounts' shows the following:
> /dev/root /mnt ext2 rw 0 0
> /dev/root /tmp1 ext2 rw 0 0
>
> NOTE: The above mount entries, do not indicate that /tmp1 contains the same
> directory tree as /var/tmp.
>
> But 'cat /proc/mounts_new' shows us the following:
> 0x6200 /mnt /var ext2 rw 0 0
> 0x6200 /tmp1 /var/tmp ext2 rw 0 0
>
> The above entries clearly indicates that /var/tmp directory of the ext2
> filesystem with fsid=0x6200 is the directory tree that resides under /tmp1
>
> Signed-off-by: Ram Pai <[EMAIL PROTECTED]>
>
> ---
> fs/dcache.c | 53
> fs/namespace.c | 35 ++---
> fs/proc/base.c | 32 +--
> fs/proc/proc_misc.c |1
> fs/seq_file.c| 77
> ++-
> include/linux/dcache.h |1
> include/linux/seq_file.h |1
> 7 files changed, 172 insertions(+), 28 deletions(-)
>
> Index: linux-2.6.17.10/fs/proc/base.c
> ===
> --- linux-2.6.17.10.orig/fs/proc/base.c
> +++ linux-2.6.17.10/fs/proc/base.c
> @@ -104,6 +104,7 @@ enum pid_directory_inos {
> PROC_TGID_MAPS,
> PROC_TGID_NUMA_MAPS,
> PROC_TGID_MOUNTS,
> + PROC_TGID_MOUNTS_NEW,
> PROC_TGID_MOUNTSTATS,
> PROC_TGID_WCHAN,
> #ifdef CONFIG_MMU
> @@ -145,6 +146,7 @@ enum pid_directory_inos {
> PROC_TID_MAPS,
> PROC_TID_NUMA_MAPS,
> PROC_TID_MOUNTS,
> + PROC_TID_MOUNTS_NEW,
> PROC_TID_MOUNTSTATS,
> PROC_TID_WCHAN,
> #ifdef CONFIG_MMU
> @@ -203,6 +205,7 @@ static struct pid_entry tgid_base_stuff[
> E(PROC_TGID_ROOT, "root",S_IFLNK|S_IRWXUGO),
> E(PROC_TGID_EXE, "exe", S_IFLNK|S_IRWXUGO),
> E(PROC_TGID_MOUNTS,"mounts", S_IFREG|S_IRUGO),
> + E(PROC_TGID_MOUNTS_NEW,"mounts_new", S_IFREG|S_IRUGO),
> E(PROC_TGID_MOUNTSTATS, "mountstats", S_IFREG|S_IRUSR),
> #ifdef CONFIG_MMU
> E(PROC_TGID_SMAPS, "smaps", S_IFREG|S_IRUGO),
> @@ -246,6 +249,7 @@ static struct pid_entry tid_base_stuff[]
> E(PROC_TID_ROOT, "root",S_IFLNK|S_IRWXUGO),
> E(PROC_TID_EXE,"exe", S_IFLNK|S_IRWXUGO),
> E(PROC_TID_MOUNTS, "mounts", S_IFREG|S_IRUGO),
> + E(PROC_TID_MOUNTS_NEW, "mounts_new", S_IFREG|S_IRUGO),
> #ifdef CONFIG_MMU
> E(PROC_TID_SMAPS, "smaps", S_IFREG|S_IRUGO),
> #endif
> @@ -692,13 +696,13 @@ static struct file_operations proc_smaps
> };
> #endif
>
> -extern struct seq_operations mounts_op;
> struct proc_mounts {
> struct seq_file m;
> int event;
> };
>
> -static int mounts_open(struct inode *inode, struct file *file)
> +static int __mounts_open(struct inode *inode, struct file *file,
> + struct seq_operations *mounts_op)
> {
> struct task_struct *task = proc_task(inode);
> struct namespace *namespace;
> @@ -716,7 +720,7 @@ static int mounts_open(struct inode *ino
> p = kmalloc(sizeof(struct proc_mounts), GFP_KERNEL);
> if (p) {
> file->private_data = &p->m;
> - ret = seq_open(fil
Re: How to query mount propagation state?
On Mon, 2007-04-16 at 12:34 +0200, Miklos Szeredi wrote:
> Currently one of the difficulties with mount propagations is that
> there's no way to know the current state of the propagation tree.
>
> Has anyone thought about how this info could be queried from
> userspace?
I am attaching two patches that I had done way back in Oct 2006
with Al Viro. I had sent these patches to Al Viro. But I forgot to
follow them up, I guess so did Al Viro.
The first patch disambiguates multiple mount-instances of the same
filesystem (or part of the same filesystem), by introducing a new
interface /proc/mounts_new.
The second patch introduces a new proc interface that exposes all the
propagation trees within a namespace. It does not show propagated
mounts residing in a different namespace (for privacy reasons). Maybe
one could modify the patch a little, to allow it; if the user has
root priviledges.
RP
PS: Sorry these are attachments instead of inline patches. I am scared
of inlining in evolution. If needed I can send inline patches through
mutt.
>
> Thanks,
> Miklos
This patch disambiguates multiple mount-instances of the same
filesystem (or part of the same filesystem), by introducing a new
interface /proc/mounts_new. The interface has the following format.
FSID mntpt root-dentry fstype fs-options
NOTE: root-dentry is the path to the dentry w.r.t to the root dentry of the
same filesystem.
for example: lets say we attempt the following commands
mount --bind /var /mnt
mount --bind /mnt/tmp /tmp1
'cat /proc/mounts' shows the following:
/dev/root /mnt ext2 rw 0 0
/dev/root /tmp1 ext2 rw 0 0
NOTE: The above mount entries, do not indicate that /tmp1 contains the same
directory tree as /var/tmp.
But 'cat /proc/mounts_new' shows us the following:
0x6200 /mnt /var ext2 rw 0 0
0x6200 /tmp1 /var/tmp ext2 rw 0 0
The above entries clearly indicates that /var/tmp directory of the ext2
filesystem with fsid=0x6200 is the directory tree that resides under /tmp1
Signed-off-by: Ram Pai <[EMAIL PROTECTED]>
---
fs/dcache.c | 53
fs/namespace.c | 35 ++---
fs/proc/base.c | 32 +--
fs/proc/proc_misc.c |1
fs/seq_file.c| 77 ++-
include/linux/dcache.h |1
include/linux/seq_file.h |1
7 files changed, 172 insertions(+), 28 deletions(-)
Index: linux-2.6.17.10/fs/proc/base.c
===
--- linux-2.6.17.10.orig/fs/proc/base.c
+++ linux-2.6.17.10/fs/proc/base.c
@@ -104,6 +104,7 @@ enum pid_directory_inos {
PROC_TGID_MAPS,
PROC_TGID_NUMA_MAPS,
PROC_TGID_MOUNTS,
+ PROC_TGID_MOUNTS_NEW,
PROC_TGID_MOUNTSTATS,
PROC_TGID_WCHAN,
#ifdef CONFIG_MMU
@@ -145,6 +146,7 @@ enum pid_directory_inos {
PROC_TID_MAPS,
PROC_TID_NUMA_MAPS,
PROC_TID_MOUNTS,
+ PROC_TID_MOUNTS_NEW,
PROC_TID_MOUNTSTATS,
PROC_TID_WCHAN,
#ifdef CONFIG_MMU
@@ -203,6 +205,7 @@ static struct pid_entry tgid_base_stuff[
E(PROC_TGID_ROOT, "root",S_IFLNK|S_IRWXUGO),
E(PROC_TGID_EXE, "exe", S_IFLNK|S_IRWXUGO),
E(PROC_TGID_MOUNTS,"mounts", S_IFREG|S_IRUGO),
+ E(PROC_TGID_MOUNTS_NEW,"mounts_new", S_IFREG|S_IRUGO),
E(PROC_TGID_MOUNTSTATS, "mountstats", S_IFREG|S_IRUSR),
#ifdef CONFIG_MMU
E(PROC_TGID_SMAPS, "smaps", S_IFREG|S_IRUGO),
@@ -246,6 +249,7 @@ static struct pid_entry tid_base_stuff[]
E(PROC_TID_ROOT, "root",S_IFLNK|S_IRWXUGO),
E(PROC_TID_EXE,"exe", S_IFLNK|S_IRWXUGO),
E(PROC_TID_MOUNTS, "mounts", S_IFREG|S_IRUGO),
+ E(PROC_TID_MOUNTS_NEW, "mounts_new", S_IFREG|S_IRUGO),
#ifdef CONFIG_MMU
E(PROC_TID_SMAPS, "smaps", S_IFREG|S_IRUGO),
#endif
@@ -692,13 +696,13 @@ static struct file_operations proc_smaps
};
#endif
-extern struct seq_operations mounts_op;
struct proc_mounts {
struct seq_file m;
int event;
};
-static int mounts_open(struct inode *inode, struct file *file)
+static int __mounts_open(struct inode *inode, struct file *file,
+ struct seq_operations *mounts_op)
{
struct task_struct *task = proc_task(inode);
struct namespace *namespace;
@@ -716,7 +720,7 @@ static int mounts_open(struct inode *ino
p = kmalloc(sizeof(struct proc_mounts), GFP_KERNEL);
if (p) {
file->private_data = &p->m;
- ret = seq_open(file, &mounts_op);
+ ret = seq_open(file, mounts_op);
if (!ret) {
p->m.private = namespace;
p->event = namespace->event;
@@ -729,6 +733,16 @@ static int mounts_open(struct inode *ino
return ret;
}
+extern struct seq_operations mounts_op, mounts_new_op;
+static int mounts_open(struct inode *inode, struct file *file)
+{
+ return (__mounts_open(inode, file, &mounts_op));
+}
+static int mounts_new_open(struct inode *inode, struct file *file)
+{
+ return __mount
How to query mount propagation state?
Currently one of the difficulties with mount propagations is that there's no way to know the current state of the propagation tree. Has anyone thought about how this info could be queried from userspace? Thanks, Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
