Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757690AbbKSQcd (ORCPT ); Thu, 19 Nov 2015 11:32:33 -0500 Received: from mail-io0-f180.google.com ([209.85.223.180]:36558 "EHLO mail-io0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756911AbbKSQc2 (ORCPT ); Thu, 19 Nov 2015 11:32:28 -0500 Date: Thu, 19 Nov 2015 10:31:34 -0600 From: Seth Forshee To: Octavian Purdila Cc: Richard Weinberger , Al Viro , "Eric W. Biederman" , linux-bcache@vger.kernel.org, device-mapper development , "linux-raid@vger.kernel.org" , "linux-mtd@lists.infradead.org" , linux-fsdevel , LSM , selinux@tycho.nsa.gov, Serge Hallyn , Andy Lutomirski , LKML , "Theodore Ts'o" Subject: Re: [PATCH v3 0/7] User namespace mount updates Message-ID: <20151119163134.GB45540@ubuntu-hedt> References: <20151117172551.GA108807@ubuntu-hedt> <20151117175506.GW22011@ZenIV.linux.org.uk> <20151117183444.GB108807@ubuntu-hedt> <20151117192141.GD108807@ubuntu-hedt> <564B8A20.9090607@nod.at> <20151119152347.GA45540@ubuntu-hedt> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4530 Lines: 103 On Thu, Nov 19, 2015 at 06:19:10PM +0200, Octavian Purdila wrote: > On Thu, Nov 19, 2015 at 5:23 PM, Seth Forshee > wrote: > > On Wed, Nov 18, 2015 at 12:00:17AM +0200, Octavian Purdila wrote: > >> On Tue, Nov 17, 2015 at 10:12 PM, Richard Weinberger wrote: > >> > Am 17.11.2015 um 20:25 schrieb Octavian Purdila: > >> >> On Tue, Nov 17, 2015 at 9:21 PM, Seth Forshee > >> >> 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 > >> >>>> 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. > > > > Hi Seth, > > > 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. > > > > Great, thanks for giving it a try and reporting the issues. No problem, looks like a promising project. > > Unfortunately I still can't run it in background mode, I get a segfault. > > I got it to reproduce as well now. Not sure why how it worked before, > probably a race condition between lkl initialization and fuse calls. > > > 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 > > > > I will reproduce it and take a look. > > > 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/ > > lklfuse allocates a fixed 100MB to the kernel and this is probably not > enough. For the short term I can add a parameter to lklfuse that > allows the user to specify the amount of memory to allocate to lkl. A > better fix would probably be to dynamically adjust the memory size of > lkl. I am thinking of using the ballon virtio driver or the memory > hotplug infrastructure. Any other suggestions? > > I created a couple of issues in github [1] that you can track if you > want - I want to avoid spamming the list with reporting progress on > them. Makes sense, I'm watching those issues now and will direct any furure discussion there. Thanks! -- 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/