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

[Michal Hocko]

On Tue 14-07-26 17:00:37, Richard Chang wrote:
> 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.

Correct.

> 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.

fatal_signal_pending takes care of all fatal signals - i.e. when tasks
doesn't really return to userspace because it dies along the way so it
doesn't realize there was a kernel internal signal ever triggered.

> 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.

True the placement would need to be done very carefully.

> 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.

This is relatively new code and a broken one I would say.

> 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?

I am not insisting both to be addressed in the same patch. But building
more on top of a broken behavior is not healthy either.
In the current state this should be as easy as turning signal_pending
into fatal_signal_pending and try_to_freeze at the pro-active reclaim
entry point which should be safe from the freezer POV.

-- 
Michal Hocko
SUSE Labs