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

On (26/08/20 11:34), Peter Zijlstra wrote:
> On Thu, Aug 20, 2026 at 06:24:29PM +0900, Sergey Senozhatsky wrote:
> > On (26/08/20 11:10), Peter Zijlstra wrote:
> > > On Thu, Aug 20, 2026 at 06:07:18PM +0900, Sergey Senozhatsky wrote:
> > > > On (26/08/20 10:49), Peter Zijlstra wrote:
> > > > > Message-ID: <[email protected]>
> > > > > 
> > > > > On Wed, Aug 19, 2026 at 12:03:32PM +0200, Miklos Szeredi wrote:
> > > > > > Why is this unsafe exactly?  Does that unsafeness apply to
> > > > > > filesystems?  If so why do we allow freezing while blocked on
> > > > > > sb_start_write()?
> > > > > 
> > > > > Getting frozen with lock A held, while another task is blocked on A in
> > > > > an unfreezable state results in the system not being freezable.
> > > > 
> > > > Right, but then the system says "suspend failed" (tasks refuse to freeze
> > > > after 20sec) and just thaws everything back in?
> > > 
> > > People don't like suspend failing. People like to close their lid, throw
> > > laptop in bag, and expect laptop to not cook itself to death.
> > 
> > Sure, that's exactly the problem I'm looking at.  Throwing TASK_FREEZABLE
> > addresses some of the cases.  Failing laptop suspend because of uncontended
> > VFS lock is not an uncommon scenario for us.  Ideally, however, we need
> > some sort of server/client aware suspend, maybe moving clients to cgroup C
> > and server to cgroup S, and freezing those in strict order.  Or teaching PM
> > that some tasks cannot be frozen in random order during suspend (e.g. a
> > special flag PM_FREEZE_ME_LAST).
> > 
> > fuse is not the only subsystem that doesn't fit current random order suspend.
> > Another troublemaker for us is notify, which basically has the same server/client
> > architecture (where both sides are user-space processes).
> 
> Then propose patches creating freeze order.
>
> 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?