Re: [PATCH v2] mm: vmscan: abort proactive reclaim early when freezing for suspend

[Richard Chang]

Hi Michal,

On Fri, Jul 10, 2026 at 2:27 PM Michal Hocko <mhocko@xxxxxxxx> wrote:
>
> I believe this is a wrong behavior. Freezer should be invisible from the
> userspace POV. Your patch makes the pre-existing problem much more
> visible. I believe we need a slightly different approach. Should we
> try_to_freeze in well defined places in the reclaim and turn
> user_proactive_reclaim to fatal_signal_pending?
>

I believe your perspective is that we should avoid -EINTR during
suspend by transparently pausing and resuming the task rather than
aborting the system call.
However, this approach faces a few constraints:
1. fatal_signal_pending() only addresses SIGKILL, leaving us to still
handle standard non-fatal signals, such as SIGINT/Ctrl+C, for
userspace callers.
2. Calling try_to_freeze() deep within the reclaim path is complex, as
it may hold various locks (such as RCU, page, or cgroup locks) while
suspended.
3. Since -EINTR is already the established return behavior in
user_proactive_reclaim() when interrupted by signal_pending(), robust
userspace callers should already be equipped to handle this early
return.

On the other hand, the freezer timeout/suspend failure is a genuine
bug currently impacting Android devices in the field. The proposed
patch safely addresses this immediate issue by leveraging the
pre-existing -EINTR exit path in user_proactive_reclaim(). Could we
focus on the current patch and open a separate discussion for a more
ideal, long-term design regarding freezer invisibility as a follow-up?