On Wed, Feb 6, 2013 at 10:56 AM, Han-Wen Nienhuys <hanw...@gmail.com> wrote: > On Wed, Feb 6, 2013 at 2:11 AM, Li Fei <fei...@intel.com> wrote: >> >> 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 above, make fuse daemon frozen after all all user >> space processes frozen and during the kernel threads frozen phase. >> PF_FREEZE_DAEMON flag is added to indicate that the current thread is >> the fuse daemon, set on connection, and clear on disconnection. >> It works as all fuse requests are handled during user space processes >> frozen, there will no further fuse request, and it's safe to continue >> to freeze fuse daemon together with kernel freezable tasks. > > Will this work correctly if one FUSE daemon is opening files in from > another FUSE filesystem?
As long as only non-fuse-daemon processes are generating the requests (i.e. fuse daemons don't spontaneously generate new requests) it should work. I think more problematic is that userspace processes tend to communicate with each other, sometimes in a non-trivial way. For example gethostbyname(3) will turn to nscd(8) for name service cache results. So a fuse daemon that might call gethostbyname() should mark nscd with PF_FREEZE_DAEMON but that requires careful audit (or nscd might mark itself PF_FREEZE_DAEMON for that reason). And that's just an example of a most basic C library function. There are many more such hidden interactions that can trip up this scheme. 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/
