Re: [PATCH] freezer: configure user space process frozen along withkernel threads
From: Pavel Machek
Date: Wed Feb 20 2013 - 17:39:17 EST
On Wed 2013-02-20 05:51:49, Eric W. Biederman wrote:
> Li Fei <fei.li@xxxxxxxxx> writes:
> > There is well known issue that freezing will fail in case that fuse
> > daemon is frozen firstly with some requests not handled, as the fuse
> > usage task is waiting for the response from fuse daemon and can't be
> > frozen. To solve the issue as above, make fuse daemon frozen after
> > all user space processes frozen and during the kernel threads frozen
> > phase.
> > After discussion, at present it's generally agreed that:
> > 1) It's only the fuse daemon itself know definitely that it needs
> > and can be frozen together with kernel threads;
> > 2) It's helpful to expose interface that user space processes can
> > use to configure user space processes to be frozen together with
> > kernel threads.
> > More information can be found on https://lkml.org/lkml/2013/2/18/174.
> > To support the requirement above, attribute /proc/<PID>/freeze_late
> > is added, writing 1 to it will make the process to be frozen together
> > with kernel threads, and writing 0 to it will make the process to be
> > frozen together with user space processes.
> There are no permission checks on this interface at all which
> potentially could make freeze late loose all meaning. Certainly
> operating without permission checks needs some justification.
> Then I have the question how does this scale. Which processes are ok to
> have the freeze late bit set?
> But even more than that fuse is setup to allow unprivileged mounts and
> mostly untrusted processes to act as filesystems, whith a nice kernel
> wrapper. Now we are going to trust those filesystems with the ability
> to stop the kernel from freezing?
> That seems inherently wrong.
It would be cool to treat fuse as a kind of IPC, and have rule that all
processes waiting for fuse need to be in S state (or at least freezeable/killable).
Unfortunately fuse does support mmap, and the way VFS is done, putting
tasks waiting for fuse in S state is not easy.
We could use help in that area...
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
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/