linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shaya Potter <spotter@cs.columbia.edu>
To: Al Boldi <a1426z@gawab.com>
Cc: torvalds@osdl.org, linuxram@us.ibm.com, viro@ftp.linux.org.uk,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	rob@landley.net, Miklos Szeredi <miklos@szeredi.hu>
Subject: Re: [PATCH 12/18] shared mount handling: bind and rbind
Date: Wed, 16 Nov 2005 15:21:43 -0500	[thread overview]
Message-ID: <1132172504.8037.24.camel@localhost.localdomain> (raw)
In-Reply-To: <200511162303.33103.a1426z@gawab.com>

On Wed, 2005-11-16 at 23:05 +0300, Al Boldi wrote:
> Shaya Potter wrote:
> > I created a patch years ago that creates a chain of "chroot" points, and
> > any past chroot point would be considered a place that follow_dotdot
> > would consider a root.  There didn't seem much interest in the patch
> > though.
> 
> Could you resubmit this patch for possible inclusion in 2.6.16, and make it a 
> runtime option such that the default behaviour remains unchanged?

resubmit?  It was a long long time ago (middle of 2.4 era)  I'd have to
find it, who knows if its still around.

Conceptually it was pretty simple, basically instead of just overwriting
the fs struct root/rootmnt you create a linked list of them (appending
on every chroot).  I think I might have had a seperate struct to
maintain that linked list (it wasn't the best code in the world).

follow_dotdot is then modified so that the code

if (nd->dentry == current->fs->root &&
	nd->mnt == current->fs->rootmnt) {
	read_unlock(&current->fs->lock);
	break;
}

instead of being just a single test, loops over every element in the
linked list.  Hence, if you are ever at a "chroot" point, you get a
root, so solves the simple problem of breaking out of a chroot by
calling chroot() again.  In the normal case (no chroot), there should be
no real performance hit, as it would hit the loop once.

However, as others have said, if you can make a device node, then you
can break out of it in other ways.

Now, there are other things one has to take care of.  

1) Obvious: cleaning up the list on process termination.
2) Obvious: propagating list to child processes.

and probably some less obvious things that I don't remember or didn't
even consider at the time.

  reply	other threads:[~2005-11-16 20:21 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-08  2:01 [PATCH 12/18] shared mount handling: bind and rbind Al Viro
2005-11-08 14:11 ` Miklos Szeredi
2005-11-08 15:48   ` Ram Pai
2005-11-08 15:55     ` Miklos Szeredi
2005-11-09 18:44       ` Ram Pai
2005-11-09 18:59         ` Linus Torvalds
2005-11-09 19:26           ` Al Viro
2005-11-09 19:28           ` Ram Pai
2005-11-16  3:29           ` Rob Landley
2005-11-16  3:53             ` Linus Torvalds
2005-11-16  5:35               ` Al Boldi
2005-11-16  8:19                 ` Miklos Szeredi
2005-11-16  9:10                   ` Rob Landley
2005-11-16 10:14                     ` Miklos Szeredi
2005-11-16 13:59                   ` Shaya Potter
2005-11-16 16:35                     ` Miklos Szeredi
2005-11-16 20:05                     ` Al Boldi
2005-11-16 20:21                       ` Shaya Potter [this message]
2005-11-16  8:47                 ` Rob Landley
2005-11-16  8:41               ` Rob Landley
2005-11-16 16:18                 ` Linus Torvalds
2005-11-09 10:54 ` Miklos Szeredi
2005-11-09 14:31   ` Al Viro
2005-11-09 15:22     ` Miklos Szeredi
2005-11-09 15:56       ` Al Viro
2005-11-09 16:33         ` Miklos Szeredi

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=1132172504.8037.24.camel@localhost.localdomain \
    --to=spotter@cs.columbia.edu \
    --cc=a1426z@gawab.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    --cc=miklos@szeredi.hu \
    --cc=rob@landley.net \
    --cc=torvalds@osdl.org \
    --cc=viro@ftp.linux.org.uk \
    /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).