From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 545BD3D8912 for ; Wed, 15 Jul 2026 08:49:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784105386; cv=none; b=JRlLfl0Z32saC86BNwWdiOjvNKGDwNbhmzYRFAX6Kwx4pUNF4qy2tpsElIB1Ox/lU0G/OKwL2Vu9C/liDaSS8aWnQhM3RkCx6KsoHRX0Uuf2LYiukqapci5u0/+5+k3aL77fLBQ5aryzHo3gf5SWB/Y+pldIPaek9YTPRnWtEKE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784105386; c=relaxed/simple; bh=EcnxmopFIkg/7NIuOfA1iR5rSpoqW9eKa4C7+FcRDJc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JO2WpGFocksSwOgbRApFROUihMnXrYdvCgtVmG2hrsoZlLOg39FoPI16o6Q4MgRpOkVmsjsz1YrKuPgVazunxHrieVxI7jNfV/5yRVRtLSXlrmDV6qthQ1Py/cMxe4eiqw1HO0GteeNtx2gavdCnd5KMw3IBxzJ0QmTUolOTZwk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=YhfyHTLI; arc=none smtp.client-ip=209.85.128.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="YhfyHTLI" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-493c19bad03so45972895e9.2 for ; Wed, 15 Jul 2026 01:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1784105376; x=1784710176; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=k42uWNrgks4Qfkke7I4gbqE7wVDID9Htt0sjV8klUNI=; b=YhfyHTLIdtv2tNgJH40AT5AdOvJg7mtMYb7jxXFdgIzFq1EQIvOaYOJq9K6HiPgm8S N4HmCH/zuIoteZKSej7zBE9qqkWk2i8gAm8m3l5D+VlMHu+Ac9wcH0VjUtev77OUfVii 0RPhEtoXwMbhAeFeUj9kGYpZtfREr3x/YIZxaUPsp1Q6IdHD0bsUpxiMQfIK28ZDIA7N 7QhT0eTy9iyPRjguAD78S86DlVBx1MzYe7Tw4fBY5SwXdVTSQiKJfDHBx+LrpMfcGKGY bCZcDjc9rheUhf5u2lt8YTLISmDuiKTTJ6/KR8vCNrLl5u600ke2qv9vZbwy7MWCmXz7 E7XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784105376; x=1784710176; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=k42uWNrgks4Qfkke7I4gbqE7wVDID9Htt0sjV8klUNI=; b=TE4qfKLDN3BHEqK2kLlHv+fMO7oF0qjYQ+ja6mwJgTgrRkZifNVcW92CGxlAElfLNq UE/3D0si/w4yJDBa03tvGxumg0d+yug1NHmES2r1Ratt+Dvg3iZSXC7LnyPAEYte3Q4T 9B8kNKcZiX8JYPS9ptnq0mNY06MpTnsLW1hSxDRvD2bA/6bwpwdilQHu+0Tou3RuD0LV MIEiJcEsk1GNMD3SDd17P9GH3JM+TBE3/RHM8k6yZYEIc6Cq/67u22Wd7+9LLDtSEXE9 ugu30osWoJ+pkQ5ScGYtFSBgJrUL4LZEKZXbAAGEiI9+FJbIPN2cn0ZNXJNRGJyclH7V h/8A== X-Forwarded-Encrypted: i=1; AHgh+Rp0wPE4aABXEd6DZuBvWJvRFbs0INRnbWKN1qS8hUQbDnFHwfLETqEBlqeYG1CbhA5sKbVLB3UD8mu9uKY=@vger.kernel.org X-Gm-Message-State: AOJu0YyrlQ+6nbfblzmTMPtzi5dnKhQQriFEYoTOLAibhUl3Ksn6uBzd 8NcE11OWBrKKmDKEvEvTDCYkVOeQhPcpU6Pm9l3KC3nWG+6ZycdXMkrlchgggqmPdXE= X-Gm-Gg: AfdE7cnlcRHyyOa6fzqO4twZ9iVjvQnZWzwARPmStbAE11xp9WfpBTLo+KZa4GMPm4f QdxmeWb/IMp+kQdNytqgia5lSSe0xeC3Rjf++NXt4KwMxIrv918uTyYzBwHqW/g9BH2BaRFTSbu DLFpxYLiCC9iuy24L1pilqDCiygAsGfipmSVyBFcuz9SwwQCftdNYH1fCQz3wPaPAWP8bZk95Hz 4zmMHhgpErCxgd9rFtkBlusT35yIsCiJ30XSt0QwCU5x8AfVW5iJk7Xsl606M7+KCA426ozrfq9 LC2Nji5XapgsR3WJA+ag4c3xaJmqBw3OX0oFFboMN+9uEpA+CEh5qyJhqTSmBEN4wOaA9zSua+2 1wlP7u42ST85j8tHV7eF7juvH6GDD88JjeUysXXQ70s44ir3SoXDfp5m2xOSe04wZ59P8qwcxC6 X/cYsNw7r7Oz2nMtuc9X3sPHHfQA== X-Received: by 2002:a05:600c:56d4:b0:493:e49e:f58 with SMTP id 5b1f17b1804b1-4953c14efd7mr15878345e9.4.1784105376341; Wed, 15 Jul 2026 01:49:36 -0700 (PDT) Received: from localhost (109-81-95-153.rct.o2.cz. [109.81.95.153]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f4634debesm14755224f8f.8.2026.07.15.01.49.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jul 2026 01:49:35 -0700 (PDT) Date: Wed, 15 Jul 2026 10:49:35 +0200 From: Michal Hocko To: Richard Chang , Oleg Nesterov Cc: Andrew Morton , Kairui Song , Qi Zheng , Shakeel Butt , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Johannes Weiner , David Hildenbrand , Lorenzo Stoakes , Suren Baghdasaryan , "T . J . Mercier" , Martin Liu , Minchan Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm: vmscan: abort proactive reclaim early when freezing for suspend Message-ID: References: <20260709072231.3163082-1-richardycc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: [Add Oleg] On Wed 15-07-26 15:56:49, Richard Chang wrote: > Hi Michal, > Thanks for the patch. > Yes, inserting try_to_freeze() at that point carries low risk. > However, there are still a few issues: > > 1. As I understand it, fatal_signal_pending() only checks for SIGKILL > (via sigismember(..., SIGKILL)). > It does not return true for SIGINT (Ctrl+C), even if the signal is > unhandled and will eventually terminate the task. > If we switch to fatal_signal_pending, a large proactive reclaim task > will continue reclaiming until the loop finishes. OK, I see you concern now. The code is a bit confusing in this respect. You are right that fatal_signal_pending returns true only if SIGKILL is flagged. You need to have a look at the signal delivery path though. If there is a terminating signal sent and there is a default handler (sig_fatal) then complete_signal will add SIGKILL to kill the whole process group. > 2. try_to_freeze() does not clear the TIF_SIGPENDING flag. When the > task resumes and continues the user_proactive_reclaim() loop, the next > iteration of the inner loop will immediately abort. You are right. I forgot that try_to_freeze is not really aimed to be used for user processes. Rather than trying to enforce explicit try_to_freeze and dealing with pending signals I believe the right approach would be to instead simply do the following. Oleg you haven't been CCed from the top of the thread but TL;DR is that we need to freeze a user task performing pro-active memory reclaim that might take long. Currently we are calling signal_pending to bail out but that leaks EINTR which is bad as freezing task has a side effect of terminating it. diff --git a/mm/vmscan.c b/mm/vmscan.c index 35c3bb15ae96..336af76d2a28 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -7909,8 +7909,13 @@ int user_proactive_reclaim(char *buf, unsigned long batch_size = (nr_to_reclaim - nr_reclaimed) / 4; unsigned long reclaimed; + /* + * Make sure that we enter freezer without delaying much and + * leaking EINTR when that happens but also take care of + * fatal signals to terminate. + */ if (signal_pending(current)) - return -EINTR; + return -ERESTARTSYS; /* * This is the final attempt, drain percpu lru caches in the -- Michal Hocko SUSE Labs