From: Miklos S. <mi...@sz...> - 2013-02-14 10:32:05
|
On Wed, Feb 13, 2013 at 9:16 PM, Pavel Machek <pa...@uc...> wrote: > On Wed 2013-02-13 18:34:16, Miklos Szeredi wrote: >> On Tue, Feb 12, 2013 at 2:17 PM, Miklos Szeredi <mi...@sz...> wrote: >> > On Tue, Feb 12, 2013 at 2:13 PM, Miklos Szeredi <mi...@sz...> wrote: >> >> On Tue, Feb 12, 2013 at 11:46 AM, Pavel Machek <pa...@uc...> 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". |