On Wed, Feb 13, 2013 at 9:16 PM, Pavel Machek <pa...@ucw.cz> wrote: > On Wed 2013-02-13 18:34:16, 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 > > And it looked so easy and nice... > >> 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. > > Is it even valid for get_user_pages to be used on FUSE?
Disabling all mmap (which is what you question) would make fuse a useless piece of toy. So yes, definitely it's valid. > > What happens if fused tries to do some operation (it is userspace, it > can do lot of operations) that needs one of those locks? E.g. mmap_sem is taken for the process _accessing_ a vma for a fuse filesystem. The server process better not do this (i.e. access the filesystem it's serving) or deadlocking (*) is basically guaranteed. That's nothing new. The thing that makes this hard for freeze is that those locks (mmap_sem, etc.) are only indirectly related to the fuse filesystem by the _actions_ of a process (accessing mmaped fuse area). Thanks, Miklos (*) userspace induced deadlocks in fuse are not hard deadlocks, they can be forced open by "umount -f" or "echo > /sys/fs/fuse/connections/$DEV/abort". -- 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/
