Re: [PATCH v3 0/7] User namespace mount updates
From: Seth Forshee
Date: Thu Nov 19 2015 - 10:24:47 EST
On Wed, Nov 18, 2015 at 12:00:17AM +0200, Octavian Purdila wrote:
> On Tue, Nov 17, 2015 at 10:12 PM, Richard Weinberger <richard@xxxxxx> wrote:
> > Am 17.11.2015 um 20:25 schrieb Octavian Purdila:
> >> On Tue, Nov 17, 2015 at 9:21 PM, Seth Forshee
> >> <seth.forshee@xxxxxxxxxxxxx> wrote:
> >>>
> >>> On Tue, Nov 17, 2015 at 08:12:31PM +0100, Richard Weinberger wrote:
> >>>> On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee
> >>>> <seth.forshee@xxxxxxxxxxxxx> wrote:
> >>>>> On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
> >>>>>> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
> >>>>>>
> >>>>>>> Shortly after that I plan to follow with support for ext4. I've been
> >>>>>>> fuzzing ext4 for a while now and it has held up well, and I'm currently
> >>>>>>> working on hand-crafted attacks. Ted has commented privately (to others,
> >>>>>>> not to me personally) that he will fix bugs for such attacks, though I
> >>>>>>> haven't seen any public comments to that effect.
> >>>>>>
> >>>>>> _Static_ attacks, or change-image-under-mounted-fs attacks?
> >>>>>
> >>>>> Right now only static attacks, change-image-under-mounted-fs attacks
> >>>>> will be next.
> >>>>
> >>>> Do we *really* need to enable unprivileged mounting of kernel filesystems?
> >>>> What about just enabling fuse and implement ext4 and friends as fuse
> >>>> filesystems?
> >>>> Using the approaching Linux Kernel Libary[1] this is easy.
> >>>
> >>> I haven't looked at this project, but I'm guessing that programs must be
> >>> written specifically to make use of it? I.e. you can't just use the
> >>> mount syscall, and thus all existing software still doesn't work?
> >>>
> >>
> >> The projects includes a lklfuse program that uses fuse to mount a
> >> fileystem image.
> >
> > Cool. I gave it a try.
> > It seems to work fine, but only if I run it in foreground (using -d)
> > otherwise fuse blocks every filesystem request.
> >
>
> Now it should work in the background as well, thanks for reporting the issue.
I'm playing with lklfuse now, it's surprisingly easy to get up and
running. I did have a few problems though that I thought you'd like to
know about.
Unfortunately I still can't run it in background mode, I get a segfault.
It's working fine on light workloads, but I'm having issues when I start
trying to stress it. In a couple runs of the stress-ng filesystem
stressors I saw both stress-ng and lklfuse get stuck in uninterruptible
sleep during the first run, and during the second I got some OOM errors
in lklfuse followed by I/O errors and eventually a journal error that
cause the filesystem to go read-only.
The command I used for the first run was:
stress-ng --class filesystem --all 0
And for the second:
stress-ng --class filesystem --seq 0 -v -t 60
There really wasn't anything interesting in the lklfuse output for the
first run, but for the second run I pasted the output here:
http://paste.ubuntu.com/13346993/
I still need to compare this to other fuse filesystems since I haven't
tried this kind of stress test on any others.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/