On Wednesday, February 13, 2013 06:34:16 PM Miklos Szeredi wrote: > On Tue, Feb 12, 2013 at 2:17 PM, Miklos Szeredi <mik...@szeredi.hu> wrote: > > On Tue, Feb 12, 2013 at 2:13 PM, Miklos Szeredi <mik...@szeredi.hu> wrote: > >> On Tue, Feb 12, 2013 at 11:46 AM, Pavel Machek <pa...@ucw.cz> wrote: > >> > >>> (After all, with FUSE, filesystem clients are just doing IPC. In ideal > >>> world, that would be freezeable and killable with -9). > > Well, I thought this can be constrained to locks directly related to > the fuse filesystem itself, but it can't... The reason is page > faults. Pretty much everyone and their brother uses get_user_pages*, > holding various locks (mmap_sem for sure but others as well). A fuse > filesystem frozen during a page read will block those. > > Separating those parts of the kernel that can be frozen from those > that can't looks increasingly difficult. > > So I think the PF_FREEZE_DAEMON idea (the patch from Li Fei that > started this thread) may still be our best bet at handling this > situation. The idea being that pure "originator" processes (ones that > take no part in serving filesystem syscalls) can be frozen up-front. > Then the "fuse daemon" (or "server") processes are hopefully in a > quiescent state and can be frozen without difficulty. > > Unfortunately it needs help from userspace: the kernel can't easily > guess which processes are part of a "fuse daemon" and which aren't. > Fortunately we have a standard library (libfuse) that can tell it to > the kernel for the vast majority of cases.
So basically the idea would be to introduce something like PF_FREEZE_LATE for user space processes that need to be frozen after all of the other (non-PF_FREEZE_LATE) user space processes have been frozen and hack fuse to use that flag? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
