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
On Mon, 2007-04-09 at 12:07 -0500, Serge E. Hallyn wrote:
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
- need to set up mount propagation from global namespace to private
ones, mount(8) does not yet have options to configure propagation
Hmm, I guess I get lost using my own little
Ok. I have shared subtree patches getting ready for review. I have
totally revamped the code from what I had sent last time, incorporating
all valuable comments Miklos had made. Offcourse I am yet to finish a
document that Andrew Morton had requested.
The patch snapshot at:
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
[])
{
if(clone(myfunc, somemem, CLONE_NEWNS|SIGCHLD, NULL)) {
wait(NULL);
} else {
printf(clone failed\n);
}
printf(exit\n);
}
Hope this helps,
RP
Gracias,
decebel
On 8/19/05, Ram Pai [EMAIL PROTECTED] wrote:
On Thu, 2005-08-18
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
48 matches
Mail list logo
