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

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.

Using cgroups for this also doesn't sound right.