Re: [PATCH v2 2/4] fs: allow all writers to be frozen

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2025-04-02 at 17:32 +0200, Christian Brauner wrote:
[...]
> Jan, one more thought about freezability here. We know that there
> will can be at least one process during hibernation that ends up
> generating page faults and that's systemd-journald. When systemd-
> sleep requests writing a hibernation image via /sys/power/ files it
> will inevitably end up freezing systemd-journald and it may be
> generating a page fault with ->mmap_lock held. systemd-journald is
> now sleeping with SB_FREEZE_PAGEFAULT and TASK_FREEZABLE. We know
> this can cause hibernation to fail. That part is fine. What isn't is
> that we will very likely always trigger:
> 
> #ifdef CONFIG_LOCKDEP
>         /*
>          * It's dangerous to freeze with locks held; there be dragons
> there.
>          */
>         if (!(state & __TASK_FREEZABLE_UNSAFE))
>                 WARN_ON_ONCE(debug_locks && p->lockdep_depth);
> #endif
> 
> with lockdep enabled.
> 
> So we really actually need percpu_rswem_read_freezable_unsafe(),
> i.e., TASK_FREEZABLE_UNSAFE.

The sched people have pretty strong views about people not doing this,
expressed in the comment in sched.h and commit f5d39b020809
("freezer,sched: Rewrite core freezer logic") where most of the _unsafe
variants got removed with prejudice.

If we do get into this situation the worst that can happen is that
another upper lock acquisition triggers a hibernate failure and we thaw
everything, thus we can never truly deadlock, which is the fear, so
perhaps they might be OK with this.  Note that Rafael's solution to
this was to disable lockdep around hibernate/suspend and resume, which
is another possibility.

Regards,

James