On Wed, 2008-02-20 at 09:31 -0700, Matthew Wilcox wrote:
On Wed, Feb 20, 2008 at 04:04:22PM +, Al Viro wrote:
It's less about the form of representation (after all, we generate poll
events when contents of that sucker changes, so one *can* get a consistent
snapshot of the entire thing)
On Wed, 2008-02-20 at 17:27 +0100, Miklos Szeredi wrote:
On Wed, Feb 20, 2008 at 04:39:15PM +0100, Miklos Szeredi wrote:
mountinfo - IMO needs a sane discussion of what and how should be shown
wrt propagation state
Here's my take on the matter.
The propagation tree can be
with CONFIG_PROC_FS=n, since it was
impossible to disable CONFIG_PROC_FS. Looking for ideas on how to disable
CONFIG_PROC_FS.
Signed-off-by: Ram Pai [EMAIL PROTECTED]
---
fs/dcache.c | 59 +++
fs/namespace.c |2 +
fs
On Thu, 2008-01-31 at 10:17 +0100, Miklos Szeredi wrote:
From: Ram Pai [EMAIL PROTECTED]
...snipped...
IDR ids are 'int' but they are always positive (AFAICT), but yeah,
maybe this is confusing.
The new exported-to-everyone dentry_path() probably could do with a bit
more documentation
file, instead of
extending /proc/mounts.
This patch is the first attempt at doing that, as well as fixing the
issues found in the previous submission.
Thanks,
Miklos
---
From: Ram Pai [EMAIL PROTECTED]
/proc/mounts in its current state fail to disambiguate bind mounts, especially
On Mon, 2008-01-21 at 22:25 +0100, Miklos Szeredi wrote:
You have removed the code that checked if the peer or
master mount was in the same namespace before reporting their
corresponding mount-ids. One downside of that approach is the
user will see an mount_id in the output
the mount with id 16 is its parent.
Testing: symlinked /etc/mtab to /proc/mounts and did some mount and df
commands. They worked normally.
Signed-off-by: Ram Pai [EMAIL PROTECTED]
---
fs/dcache.c | 53 +++
fs/namespace.c | 35
On Wed, 2007-07-11 at 11:24 +0100, Christoph Hellwig wrote:
On Sat, Jun 30, 2007 at 08:56:02AM -0400, H. Peter Anvin wrote:
Is that conjecture, or do you have evidence to that effect? Most users
of this file are using it via the glibc interfaces, and there probably
aren't all that many
the mount with id c1208c08 is its parent.
Signed-off-by: Ram Pai [EMAIL PROTECTED]
---
fs/dcache.c | 53 +++
fs/namespace.c | 25 ++
fs/pnode.c | 22 +
fs/pnode.h |2 +
fs/seq_file.c
On Thu, 2007-06-21 at 10:31 -0700, H. Peter Anvin wrote:
Ram Pai wrote:
Peter, I am not working on it currently. But i am interested in getting
it done. I have the seed set of patches which had Al Viro's ideas
incorporated. Infact those patches were sent on lkml 2 months back.
Shall we
On Fri, 2007-06-22 at 00:06 -0700, H. Peter Anvin wrote:
Ram Pai wrote:
the second patch made a /proc/propagation interface which had almost the
same fields, but also added fields to show the propagation type of the
mount as well as pointers to its peers and master depending on the type
. E.g. mountpoint + ID + relative path + type + options,
where ID uniquely identifies superblock (e.g. numeric st_dev)
and backing device (if any) is sitting among the options...
Okay, I see there has been some discussion on this earlier, based on a
proposal by Ram Pai, so it pretty much
On Thu, 2007-06-21 at 09:29 -0700, H. Peter Anvin wrote:
Ram Pai wrote:
Peter, I am not working on it currently. But i am interested in getting
it done. I have the seed set of patches which had Al Viro's ideas
incorporated. Infact those patches were sent on lkml 2 months back.
Shall we
On Wed, 2007-04-18 at 11:19 +0200, Miklos Szeredi wrote:
Allowing this and other flags to NOT be propagated just makes it
possible to have a set of shared mounts with asymmetric properties,
which may actually be desirable.
The shared mount feature was designed to ensure that the
On Wed, 2007-04-18 at 21:14 +0200, Miklos Szeredi wrote:
As I said earlier, I see a case where two mounts that are peers of each
other can become un-identical if we dont propagate the allowusermnt.
As a practical example.
/tmp and /mnt are peers of each other.
/tmp has its
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
On Tue, 2007-04-17 at 19:44 +0200, Miklos Szeredi wrote:
I'm a bit lost about what is currently done and who advocates for what.
It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be
propagated. In the /share rbind+chroot example, I assume the admin
would start by doing
On Tue, 2007-04-17 at 21:43 +0200, Miklos Szeredi wrote:
I'm a bit lost about what is currently done and who advocates for what.
It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be
propagated. In the /share rbind+chroot example, I assume the admin
would start
On Fri, 2007-04-13 at 13:58 +0200, Miklos Szeredi wrote:
On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
1. clone the master namespace.
2. in the new namespace
move the tree under /share/$me to /
for each ($user, $what, $how) {
On Fri, 2007-04-13 at 16:05 +0200, Miklos Szeredi wrote:
Thinking a bit more about this, I'm quite sure most users wouldn't
even want private namespaces. It would be enough to
chroot /share/$USER
and be done with it.
Private namespaces are only good for keeping a
Serge E. Hallyn [EMAIL PROTECTED] writes:
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
From: Miklos Szeredi [EMAIL PROTECTED]
If CLONE_NEWNS and CLONE_NEWNS_USERMNT are given to clone(2) or
unshare(2), then allow user mounts within the new namespace.
This is not flexible
On Mon, 2007-04-16 at 11:32 +0200, Miklos Szeredi wrote:
Given the existence of shared subtrees allowing/denying this at the
mount
namespace level is silly and wrong.
If we need more than just the filesystem permission checks can we
make it a mount flag settable with mount and
On Mon, 2007-04-16 at 11:56 +0200, Miklos Szeredi wrote:
Also for bind-mount and remount operations the flag has to be propagated
down its propagation tree. Otherwise a unpriviledged mount in a shared
mount wont get reflected in its peers and slaves, leading to unidentical
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
On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
1. clone the master namespace.
2. in the new namespace
move the tree under /share/$me to /
for each ($user, $what, $how) {
move /share/$user/$what to /$what
if ($how == slave) {
On Mon, 2007-04-09 at 22:10 +0200, Miklos Szeredi wrote:
The one in pam-0.99.6.3-29.1 in opensuse-10.2 is totally broken. Are
you interested in the details? I can reproduce it, but forgot to note
down the details of the brokenness.
I don't know how far removed that is from the one
systems, and just assumed
that shared subtree functionality was making its way up into mount(8).
Ram, have you been working on that?
It is in FC6. I dont know the status off upstream util-linux. I did
submit the patch many times to Adrian Bunk (the then util-linux
maintainer) and got no response. I
/~ram/readahead/sharedsubtree
and the latest set of working patches are at:
http://www.sudhaa.com/~ram/readahead/sharedsubtree/shared.0831.1
Before I formally send the patches for a review, I have bumped into a
small issue, and I am not sure about the behavior.
Al Viro's RFC at http://lwn.net
On Thu, 2005-08-18 at 12:40, Dave Schwartz wrote:
Hi list,
Not too sure if this is the right forum to ask this question but since
my requirement is around linux filesystems, I shall take this liberty
to post my question.
My requirement is to develop a kernel/user space module to add an
On Thu, 2005-08-18 at 13:27, Dave Schwartz wrote:
Hi Ram,
Thanks for the inputs. I was going over the man pages describing the
clone system call and its option of CLONE_NEWNS. Could understand the
description only in parts.
The man page suggests that this flag when set, the cloned child
On Thu, 2005-07-28 at 02:57, Miklos Szeredi wrote:
This is an example, where having struct pnode just complicates things.
If there was no struct pnode, this function would be just one line:
setting the shared flag.
So your comment is mostly about getting rid of pnode and distributing
Summary of the question:
Should the topmost mount be visible, or should the most recent
mount be visible?
consider the following command sequence
(1) cd /mnt
(2) mount --bind /usr /mnt
(3) mount --bind /bin /mnt
(4) mount --bind /var .
after step 1, the pwd of the process is
On Thu, 2005-07-28 at 04:56, Miklos Szeredi wrote:
Here is a scenario with shared subtree. Sorry it is complex.
mount --bind /mnt /mnt
mount --make-shared /mnt
mkdir -p /mnt/p
mount --bind /usr /mnt/1
mount --bind /mnt /mnt/2
At this stage the mount at /mnt/2 and /mnt
On Thu, 2005-07-28 at 12:30, Miklos Szeredi wrote:
no. there is no asymmetry as such. the propogations are working the way
they are meant to. But the confusion arises because of the mount lookup
symantics. The reason Avantika(who is doing shared subtree testing),
had this exact confusion
On Thu, 2005-07-28 at 13:35, Bryan Henderson wrote:
It wouldn't surprise me if someone is depending on mount over .. But
I'd be surprised if someone is doing it to a directory that's already been
mounted over (such that the stacking behavior is relevant). That seems
really eccentric.
On Thu, 2005-07-28 at 15:27, Bryan Henderson wrote:
Bryan, what would you expect the behavior to be when somebody mounts on
a directory what is already mounted over?
Well, I've tried to beg the question. I said I don't think it's
meaningful to mount over a directory; that one actually
On Wed, 2005-07-27 at 12:54, Miklos Szeredi wrote:
+static int do_make_shared(struct vfsmount *mnt)
+{
+ int err=0;
+ struct vfspnode *old_pnode = NULL;
+ /*
+* if the mount is already a slave mount,
+* allocate a new pnode and make it
+* a slave pnode of the
On Wed, 2005-07-27 at 12:13, Miklos Szeredi wrote:
@@ -54,7 +55,7 @@ static inline unsigned long hash(struct
struct vfsmount *alloc_vfsmnt(const char *name)
{
- struct vfsmount *mnt = kmem_cache_alloc(mnt_cache, GFP_KERNEL);
+ struct vfsmount *mnt =
, [EMAIL PROTECTED], Janak Desai [EMAIL PROTECTED],
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 0/7] shared subtree
Hi Andrew/Al Viro,
Enclosing a final set of well tested patches that implement
Al Viro's shared subtree proposal.
These
for autofs initiated operations,
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c| 176 +++---
fs/pnode.c| 12 +--
include/linux/pnode.h |3
3 files changed, 76 insertions(+), 115 deletions(-)
Index: 2.6.12.work2/fs
tree to any other
shared/private/slave/unclone tree. Also incorporates the same behavior
for pivot_root()
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c| 196 +++---
include/linux/mount.h |2
2 files changed, 173 insertions(+), 25
subtree and set up
propogation wherever needed.
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c| 660 --
fs/pnode.c| 235
include/linux/dcache.h|2
include/linux/fs.h|5
shared/private/slave/unclone
subtrees in it.
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c |9 +
1 files changed, 9 insertions(+)
Index: 2.6.12-rc6.work1/fs/namespace.c
===
--- 2.6.12-rc6.work1.orig/fs
the shared/private/slave support for VFS trees.
Signed by Ram Pai ([EMAIL PROTECTED])
fs/Makefile |2
fs/dcache.c |2
fs/namespace.c| 93 ++
fs/pnode.c| 441 ++
include/linux/fs.h|5
On Mon, 2005-07-25 at 15:44, Ram Pai wrote:
, [EMAIL PROTECTED], Janak Desai [EMAIL PROTECTED],
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 0/7] shared subtree
Hi Andrew/Al Viro,
Enclosing a final set of well tested patches that implement
my
Adds ability to clone a namespace that has shared/private/slave/unclone
subtrees in it.
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c |9 +
1 files changed, 9 insertions(+)
Index: 2.6.12.work1/fs/namespace.c
Adds the ability to bind/rbind a shared/private/slave subtree and set up
propogation wherever needed.
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c| 559 --
fs/pnode.c| 416
Adds ability to move a shared/private/slave/unclone tree to any other
shared/private/slave/unclone tree. Also incorporates the same behavior
for pivot_root()
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c | 150 +++--
1 files
On Fri, 2005-07-08 at 12:49, Miklos Szeredi wrote:
The reason why I implemented that way, is to less confuse the user and
provide more flexibility. With my implementation, we have the ability
to share any part of the tree, without bothering if it is a mountpoint
or not. The side effect of
//
//this code was developed my Miklos Szeredi [EMAIL PROTECTED]
//and modified by Ram Pai [EMAIL PROTECTED]
// sample usage:
// newmount /tmp shared
//
#include stdio.h
#include stdlib.h
#include unistd.h
#include sys/mount.h
#include sys/fsuid.h
int main(int argc, char *argv
Adds ability to unmount a shared/slave/unclone/private tree
RP
Adds ability to unmount a shared/slave/unclone/private tree
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c| 62 +++--
fs/pnode.c| 104
Adds ability to clone a namespace that has shared/private/slave/unclone
subtrees in it.
RP
Adds ability to clone a namespace that has shared/private/slave/unclone
subtrees in it.
RP
Signed by Ram Pai ([EMAIL PROTECTED])
namespace.c |9 +
1 files changed, 9 insertions(+)
Index
adds support for mount/umount propogation for autofs initiated
operations,
RP
adds support for mount/umount propogation for autofs initiated operations,
RP
Index: 2.6.12/fs/namespace.c
===
--- 2.6.12.orig/fs/namespace.c
+++
This patch adds the shared/private/slave support for VFS trees.
RP
This patch adds the shared/private/slave support for VFS trees.
Signed by Ram Pai ([EMAIL PROTECTED])
fs/Makefile|2
fs/dcache.c|2
fs/namei.c |4
fs/namespace.c
Adds the ability to unclone a vfs tree. A uncloned vfs tree will not be
clonnable, and hence cannot be bind/rbind to any other mountpoint.
RP
Adds the ability to unclone a vfs tree. A uncloned vfs tree will not be
clonnable, and hence cannot be bind/rbind to any other mountpoint.
RP
On Fri, 2005-07-08 at 04:17, Pekka Enberg wrote:
On 7/8/05, Ram [EMAIL PROTECTED] wrote:
This patch adds the shared/private/slave support for VFS trees.
Inlining the patches to email would be greatly appreciated. Here are
some comments.
+int
+_do_make_mounted(struct nameidata *nd
On Wed, 2005-04-20 at 17:42, Bryan Henderson wrote:
Well I am not aware of issues that can arise if a user is allowed to
change to some namespace for which it has permission to switch.
I think I misunderstood your proposal.
A user 'ram' creates a namespace 'n1' with a device node /dev/n1
On Wed, 2005-04-20 at 05:39, Al Viro wrote:
On Wed, Apr 20, 2005 at 01:03:40PM +0100, Jamie Lokier wrote:
It shouldn't be literally per-user - it should be possible for a user
to have several environment _when_ they want that. chroot-jail style
virtual server environments require that too.
On Wed, 2005-04-20 at 05:47, Eric Van Hensbergen wrote:
On 4/19/05, Ram [EMAIL PROTECTED] wrote:
On Tue, 2005-04-19 at 18:24, Eric Van Hensbergen wrote:
Is this sufficient to cover any exposure? What's the correct solution
for the shared sub-trees RFC? Should there be something
On Wed, 2005-04-20 at 10:09, Al Viro wrote:
On Wed, Apr 20, 2005 at 09:51:26AM -0700, Ram wrote:
Reading through the thread I assume the requirement is:
1) A User being able to create his own VFS-mount environment
2) being able to use the same VFS-mount environment from
multiple
'ram' creates a namespace 'n1' with a device node /dev/n1 having
permission 700 owned by the user 'ram'. The user than tailors his
namespace with a bunch of mount/umount/binds etc to meet his
requirement. All the processes that fork off this process see this same
setup.
Now 'ram' again logs
On Tue, 2005-04-19 at 18:24, Eric Van Hensbergen wrote:
This is again related to the FUSE permission thread, but a slightly
different idea and without a slimy hack patch.
I really want to enable users to be able to create private namespaces,
but I want to try and avoid creating a
On Sun, 2005-01-16 at 22:11, Al Viro wrote:
On Sun, Jan 16, 2005 at 01:42:09PM -0500, J. Bruce Fields wrote:
On Sun, Jan 16, 2005 at 06:06:56PM +, Al Viro wrote:
On Sun, Jan 16, 2005 at 11:02:13AM -0500, J. Bruce Fields wrote:
On Thu, Jan 13, 2005 at 10:18:51PM +, Al Viro wrote:
On Tue, 2005-02-01 at 15:21, J. Bruce Fields wrote:
On Tue, Jan 25, 2005 at 01:07:12PM -0800, Ram wrote:
If there exists a private subtree in a larger shared subtree, what
happens when the larger shared subtree is rbound to some other place?
Is a new private subtree created in the new
On Wed, 2005-02-02 at 11:45, Mike Waychison wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ram wrote:
On Tue, 2005-02-01 at 15:21, J. Bruce Fields wrote:
On Tue, Jan 25, 2005 at 01:07:12PM -0800, Ram wrote:
If there exists a private subtree in a larger shared subtree, what
On Tue, 2005-02-01 at 13:15, Mike Waychison wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(Hmm.. something is up with my quoting again..)
Ram wrote:
On Mon, 2005-01-31 at 23:02, Mike Waychison wrote:
Ram wrote:
On Fri, 2005-01-28 at 14:31, Mike Waychison wrote
On Mon, 2005-01-31 at 23:02, Mike Waychison wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ram wrote:
On Fri, 2005-01-28 at 14:31, Mike Waychison wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Al Viro wrote:
OK, here comes the first draft of proposed semantics
On Fri, 2005-01-28 at 14:31, Mike Waychison wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Al Viro wrote:
OK, here comes the first draft of proposed semantics for subtree
sharing. What we want is being able to propagate events between
the parts of mount trees. Below is a
On Tue, 2005-01-25 at 13:47, Mike Waychison wrote:
...snip...
Question 2:
When a mount gets propogated to a slave, but the slave
has mounted something else at the same place, and hence
that mount point is masked, what will happen?
Concrete example:
mount
On Mon, 2005-01-17 at 09:32, J. Bruce Fields wrote:
On Mon, Jan 17, 2005 at 06:11:50AM +, Al Viro wrote:
No - I have been missing a typo. Make that if mountpoint of what we
are moving
OK, got it, so the point is that its not clear how you'd propagate the
removal of the subtree
70 matches
Mail list logo
