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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
