Re: [PATCH v2] fuse: permit freezing while waiting for request answer

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Aug 20, 2026 at 06:47:03PM +0900, Sergey Senozhatsky wrote:

> > PM_FREEZE_ME_LAST is going to be trouble I think, before long you'll
> > need PM_FREEZE_ME_REALLY_LAST or somesuch nonsense.
> 
> We probably need more than one, yeah.  This doesn't take into consideration
> relations between tasks within a priority group.  If client A holds a lock
> and enters freezer, and client B sleeps on that lock, then this group
> cannot be suspended.  We need clients to reach some freezer checkpoint,
> instead of doing in-place freezing.
> 
> > Using cgroups for this also doesn't sound right.
> 
> This begins sounding pessimistic.
> 
> cgroup-s sounded solid to me, because this moves all the clients to that
> save freezer checkpoint when they don't hold any locks.  The only
> problem is that if a task never reaches "return from syscall" then
> we fail suspend.  (I'm only talking about user-space tasks here, in the
> context of fuse or inotify.)  Why don't cgroups sound right to you?

The cgroup hierarchy is already a mess, and the more different things
you want to stuff in there, the worse it gets.

Also, I still have machines with CGROUP=n.

Also, you'd be putting suspend success in the hands of userspace, that
sounds like a mighty fail right there.