Messages in this thread | | | Date | Thu, 14 Feb 2013 11:31:53 +0100 | Subject | Re: Getting rid of freezer for suspend [was Re: [fuse-devel] [PATCH] fuse: make fuse daemon frozen along with kernel threads] | From | Miklos Szeredi <> |
| |
On Wed, Feb 13, 2013 at 9:16 PM, Pavel Machek <pavel@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 <miklos@szeredi.hu> wrote: >> > On Tue, Feb 12, 2013 at 2:13 PM, Miklos Szeredi <miklos@szeredi.hu> wrote: >> >> On Tue, Feb 12, 2013 at 11:46 AM, Pavel Machek <pavel@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".
| |