linux-ext4 - Re: jbd2: don't wake kjournald unnecessarily

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 21 Jan 2013 18:39:39 +0100
From:	Miklos Szeredi <mszeredi@...e.cz>
To:	sedat.dilek@...il.com
Cc:	Jan Kara <jack@...e.cz>, Eric Sandeen <sandeen@...hat.com>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	Theodore Ts'o <tytso@....edu>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-next <linux-next@...r.kernel.org>
Subject: Re: jbd2: don't wake kjournald unnecessarily

On Mon, 2013-01-21 at 15:28 +0100, Sedat Dilek wrote:
> On Mon, Jan 21, 2013 at 3:07 PM, Jan Kara <jack@...e.cz> wrote:

> >   Well, I think the outputs make it pretty clear. /dev/loop0 is a mounted
> > image from fuse filesystem. Fuse daemon making filesystem accessible gets
> > frozen before /dev/loop0 gets fully written out and so jbd2 journal thread
> > hangs. Maybe Miklos (added to CC) could fill in some details / ideas but I
> > think the setup like you have never really worked...
> >
> 
> Thank you for the explanations.
> Before doing some patches for Linux Test Project and replying to
> LLVMLinux I was reflecting about FUSE when saw the 'df -h -T' line.
> You might be right, that pm_test/freezer could never be OK here.
> I wantend to test against Linux v3.8-rc4 to be sure.
> Anyway, thanks for sharing your thoughts with me!

There are several problems with this setup.  Loop over fuse has always
been problematic because of interaction with the memory management.
E.g. the kernel is trying to allocate memory and is writing out dirty
pages to the loop device then that write ends up in the userspace
filesystem process which may want to allocate additional memory to
complete the write.  This may end up deadlocking the writeout, which is
not good.  So loop over fuse (for write) is not a good idea in any case.

One way to get around this limitation is to use mountlo, which does a
loop mount in userspace using UML and fuse.   That will probably be
better. 

Unfortunately fuse has a bad interaction with the freezer as well.  The
reason for that is the freezer wants all syscalls to finish but with a
frozen userspace a fuse daemon will not be able to complete the work
necessary to finish those syscalls.  We thought about this long and hard
and there are no easy solutions.   We can allow the freezer to proceed
for cases when the syscall is directly waiting for a fuse filesystem
daemon reply.  But the syscall may be waiting for the filesystem daemon
indirectly, e.g. sleeping on i_mutex, and that's rather more difficult
to fix.  It's not impossible but it's a big project.

To conclude:  writable loop over fuse is broken and was always broken,
it should not be used.  Other solutions should work better but fuse is
currently not 

Thanks,
Miklos

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html