On Wed, Feb 13, 2013 at 10:21 PM, Rafael J. Wysocki <r...@sisk.pl> wrote: > On Wednesday, February 13, 2013 06:34:16 PM Miklos Szeredi wrote:
>> >> 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? Yes. It is essentially the same mechanism that is used to delay the freezing of kernel threads after userspace tasks have been frozen. Except it's a lot more difficult to determine which userspace tasks need to be suspended late and which aren't. Thanks, Miklos -- 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/
