From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 8A71B3C4544 for ; Wed, 15 Jul 2026 19:58:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784145509; cv=none; b=UuLUnYoG+GM9ShImjwhcGCXAJ+eKZ0g4o3B7Fx2rQtnEk4sLDIDtyUHgIbWYfT1LdKPKy+3VFPmMe8x8QXbm7j08HZgfIN0MqLuac0x9yYpzlAUWxZcEqbMHFOB3gRv1X1MdRCu5G/VgJCLFGSxoaTpE/DnRfluT8kvAuzF5FL4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784145509; c=relaxed/simple; bh=uiJzU8mgAjtFrTFNw2oF2cEsuA+GiplrlBO+UtkCakI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ej0fir/tVm4TQJn9+KftnZ8wD7EYkgcpDG8siaGby47htCdJaLjM6ZSVOs+u++y4weQSx69vyQ3g2Fg2i7t6iaVI0jkunGB1cIU2Cyuo9Wco3RplNtignzNJOLP6/wrJmgXD2OD0wR3DwdU+hOSC52+NhaGH5no4P1sE0VBo26I= 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=azX6ELet; arc=none smtp.client-ip=209.85.128.44 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="azX6ELet" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-493e8d4f4dcso43194425e9.0 for ; Wed, 15 Jul 2026 12:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1784145506; x=1784750306; 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=i7g5eqdlgx0iQFnR80osVPUiBhoOkK3DmjgOgLSkYmw=; b=azX6ELetv21pkZOeSQNbiYySXq/LJMARleq1ds9EKGI8RLwa1ZAbbKPr66O11D5dG9 1I4iloZZ2m80tfLuOPLFcSDXM0Nfiu65DJmZfD7BPfE+QTZFf1GTJBknWgqVFsvQ/RzF Z1bJLtA24xZNVB8LVt54EmysV4bcwMcUfh3DGHH5ZeNOHYk1V+tcH5CHPtjmhXrWyAgY ZSZ0a+TTjn0IVfOtLY6Be72jEy+9JCQKg+wFsGHhjvteY6+4pNv6drABW9iM5nM8RMxw vFBe36x+JA/V0Ik2Gi1EvI9Z/xFvjV48cg9ESdDkOf9RKIi4aw2Gcp8imRY4MwWCZMEX iCxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784145506; x=1784750306; 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=i7g5eqdlgx0iQFnR80osVPUiBhoOkK3DmjgOgLSkYmw=; b=EmlKRRjgtwx/srEScuGlY/bW6cyKZbF/gvjSca0MidDVGq7MQsxvIDyD1MIrIft1tA mF/2lTvxQbhTtcPMupztCK+tXwt0ul4PNUDW5fYGxrXlUgtkrgfUIQGOJkcfFNL3HMLQ JKuGx4dQ8bUMFajM2OaiLtjA2IjAanmOvNHZAgib8kCaKlb6J83Q0CE/n9GTECs9jBdu Vv6H4+MWfw5vmdPp0yRJ5Y4bDw4Kcdm1/ePdzzenKPTnjWMYa+subGeaFGsqB7Z6HQzx Ph0zHx/TPE3YMlkVnrBOy7CAqWWoiSOZdZwTH/rv8VnAGi5TWOBpab9ZOKPYYnBEk0l5 A0ZA== X-Forwarded-Encrypted: i=1; AHgh+Rq1viZ6FBWMaQb+u+t3lnpVrS0RtTyQ/0jgt3MawH1WwkKJ4HOc2K6e3DJLkfYO8kawS6eGmPzsGFtNw8o=@vger.kernel.org X-Gm-Message-State: AOJu0Yz0oqnCvwNjdxRBDm/KsBZTseOyqjpc4IwzXDSkNIVB3bmvW3RJ z2qImFfJvvycgSQqNODv4/eXq+WKWm6L6cNtZpKqAldZbms6OjWJd5OqUo2Xn1Ih69A= X-Gm-Gg: AfdE7clOklnd1NyKDxaHErSaO5D+b0OFfoGQbTA4EYYog3ZoO9OgbueywBwxj9O/N2+ Kuyre1qoY1PmTQblk3vZOGg2zURkcvEtX9qk6o3FzsfwElOqNVEbwoiAeZZMXvsZ1YLxcIe8JiW qhVg7cgzHx9trRtRm1NNgekrtOs8dGep9EgUuGgj41hoQ1Ow7uthiDPtXdnfPf9P+by9MODZR58 3P7sS0EZS+m6EtEalXzXxEFxtU+rEbX1fbZYXiiR3d3tW2EvddPBHh2EvZ4JmcO6GwABrRll8wP 1kJB6HTtYmCkFxbMW5RzA8FYVH9sWrjLN0JNDp7y48grAZjNBEBtHyScgOohRLGeWlcSbNj8tap dUh4HQ2tEHYnIkqlc8Fj6kYZ+vLeLvOGjWTPNK3XQaqCxt/joK09GX3NsU9Uif3czgRjZOmVBsE kgG7rW76oRxpYJWkBUmAtQE/p2wA== X-Received: by 2002:a05:600c:6285:b0:493:c42c:7e87 with SMTP id 5b1f17b1804b1-4953c2800b3mr44437405e9.33.1784145505792; Wed, 15 Jul 2026 12:58:25 -0700 (PDT) Received: from localhost (109-81-95-153.rct.o2.cz. [109.81.95.153]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49541e7d21fsm6718995e9.2.2026.07.15.12.58.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jul 2026 12:58:25 -0700 (PDT) Date: Wed, 15 Jul 2026 21:58:24 +0200 From: Michal Hocko To: Oleg Nesterov Cc: Richard Chang , 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: On Wed 15-07-26 19:47:37, Oleg Nesterov wrote: > Hi Michal, > > On 07/15, Michal Hocko wrote: > > > > 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. > > Sorry, I guess I don't understand the problem... the problem is that `echo $AMOUNT > $CGROUP/memory.reclaim' can take quite some time and therefore block freezer. Appart from Richard's fix to bail out on pending_signal deep in the MGLRU reclaim we have this signal_pending in user_proactive_reclaim which would leak EINTR if the source of the signal was freezer. This is IMHO undesirable. The proposed change below tries to address that problem. Makes more sense now? > > Yes, unlike EINTR, ERESTARTSYS should not leak to the caller (just in case, > debugger can see this error code). Yes, I guess this is a general constrain to any signal_pending() caller. > But I am sure you know this. And the patch looks fine to me. > > Oleg. Thanks! > > > > > 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 > > -- Michal Hocko SUSE Labs