lkml.org 
[lkml]   [2014]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 0/2] Loop device psuedo filesystem
On Mon, Sep 15, 2014 at 04:38:44PM -0400, Shea Levy wrote:
> Hi,
>
> I wanted to test these patches (to support creating and filling a disk
> image containing a btrfs filesystem and several subvolumes as an
> unprivileged user), but the build fails due to what looks like a missing
> loopfs.c in fs/loopfs (or alternatively an erroneous line in
> fs/loopfs/Makefile). I built based off of 3.17-rc5.

There's no loopfs.c, loopfs.o gets built from inode.o which is in turn
built from inode.c. I'm pretty sure the patches built when I posted
them, which seems to be 3.15-rc7 based on the branch I've got here.

Seth

>
> ~Shea
>
>
> On Tue, May 27, 2014 at 11:58:54PM +0200, Seth Forshee wrote:
> > I'm posting these patches in response to the ongoing discussion of loop
> > devices in containers at [1].
> >
> > The patches implement a psuedo filesystem for loop devices, which will
> > allow use of loop devices in containters using standard utilities. Under
> > normal use a loopfs mount will initially contain a single device node
> > for loop-control which can be used to request and release loop devices.
> > Any devices allocated via this node will automatically appear in that
> > loopfs mount (and in devtmpfs) but not in any other loopfs mounts.
> > CAP_SYS_ADMIN in the userns of the process which performed the mount is
> > allowed to perform privileged loop ioctls on these devices.
> >
> > Alternately loopfs can be mounted with the hostmount option, intended
> > for mounting /dev/loop in the host. This is the default mount for any
> > devices not created via loop-control in a loopfs mount (e.g. devices
> > created during driver init, devices created via /dev/loop-control, etc).
> > This is only available to system-wide CAP_SYS_ADMIN.
> >
> > I still have some testing to do on these patches, but they work at
> > minimum for simple use cases. It's possible to use an unmodified losetup
> > if it's new enough to know about loop-control, with a couple of caveats:
> >
> > * /dev/loop-control must be symlinked to /dev/loop/loop-control
> > * In some cases losetup attempts to use /dev/loopN when the device node
> > is at /dev/loop/N. For example, 'losetup -f disk.img' fails.
> >
> > Device nodes for loop partitions are not created in loopfs. These
> > devices are created by the generic block layer, and the loop driver has
> > no way of knowing when they are created, so some kind of hook into the
> > driver will be needed to support this.
> >
> > Thanks,
> > Seth
> >
> > [1] http://article.gmane.org/gmane.linux.kernel/1703988
> >
> > Seth Forshee (2):
> > loop: Add loop filesystem
> > loop: Permit priveleged operations within user namespaces
> >
> > drivers/block/loop.c | 137 +++++++++++++----
> > drivers/block/loop.h | 2 +
> > fs/Makefile | 1 +
> > fs/loopfs/Makefile | 6 +
> > fs/loopfs/inode.c | 360 +++++++++++++++++++++++++++++++++++++++++++++
> > include/linux/loopfs.h | 53 +++++++
> > include/uapi/linux/magic.h | 1 +
> > 7 files changed, 535 insertions(+), 25 deletions(-)
> > create mode 100644 fs/loopfs/Makefile
> > create mode 100644 fs/loopfs/inode.c
> > create mode 100644 include/linux/loopfs.h
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
> >


\
 
 \ /
  Last update: 2014-09-15 23:41    [W:0.133 / U:0.484 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site