From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) (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 66B851DFD8B for ; Tue, 14 Jan 2025 18:13:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736878392; cv=none; b=mN/HzrXZH8jFYChV1VHxu/BCrBTwA8n8dhPGUbIR0yaRW+tEE/jMf1nRffEsJHDaeXnouvunxXBDrnebZqAy59IgWoRDu1nu7SX9HHMo7RLCzzip6uiMqbwujIfvpHsC4XniwETpjsyoDEwOrzshTcNmGdspE0yQn9a+gMvpGl0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736878392; c=relaxed/simple; bh=bQ6W1NiCOf1EObjIIE/DMh3nvS6huNmcJeUX53i8VZ8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=r+YyAbRKsLBC7l4uyGFrsP8zcQTtxVl2WdNZuFulyFdobDP0LI2dxVGKUBFwRm+JmvzLBC6ZuHMq5JsP87ch2G2bF7GeFB6NpQa41yun5fMVqZhERxkiU7yWzWQTR49N++cqtoRvaotjrWdvEBU95VW5sokoQq8Kjqo3fQfPWfU= 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=VXPn7Xr/; arc=none smtp.client-ip=209.85.218.50 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="VXPn7Xr/" Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-aa6b4cc7270so824229666b.0 for ; Tue, 14 Jan 2025 10:13:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1736878389; x=1737483189; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=/PzmWEG1n7zg8r6BypqksffUkD59L7DefGMNLqR9DfU=; b=VXPn7Xr/DnrlFBG/IG8PenfU+fH31X2shNkthIsf89LTzR/38vfxugK4iKYzw5Y+qa cg9h48p6/PheZPpeC9bgE7WEQ4UpfA77xuK6ny2TkOX//B3/pJgt6YZ8Ki67LM9qu8sn xAoXIRSoSUlhVpphqAdq0Nj5ZMnSqshHs5SraAps2VdWD9750sR+cpBNYFus8sLSeJXi 3Nif9OzgGCrm4X9f3HP+3UzSV6YAiGrSfaTmhuaPZ05qrf36fOV0S3ygbNX6Y3LfnP6m jif6l5EY4AiqN2ER5f3o7qf/LbzzfaKpIs2Yhzp5PIgN53SoOoKE4W5elo42O5QjOZ2R 0A1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736878389; x=1737483189; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/PzmWEG1n7zg8r6BypqksffUkD59L7DefGMNLqR9DfU=; b=XfrfKE+EkO3hHaMHPsrsld3konqhPX8RV+F4ODwI9l8KM2rOQDxcpMBu+01uhzU4oG KZyebn5NC+gS7IJ4w+tKDU/FGlE1C3D4Bh/E+HuzG1wPNMWCs7RlaAxcgS/bLlcrTHqI AVzCyZaL2lnOALJORdhCX/P2zoenP3bkgjguTB58ATc3pWzM8FeJu4MZjiELeyVIimzT C+BzgGeSNy6EpxRzOdQn+pU8PzjNv5DzLKjgQ40TjJRPQXKc+WPUddSIOzbBpgwenipR 1BOhTOsou7vFldp+lyMvhdCDR4dyXfZcTGPgBiugZKiLbSccZGK5P41iMterizog8P36 9tQg== X-Forwarded-Encrypted: i=1; AJvYcCVY39kag1SzmhVEjR2mpdmFqUVfCdBryxoKwiUDBZNsO9AOddsZPz3nRWG9JxPJVq9QZ4EbjbMk7BthdrM=@vger.kernel.org X-Gm-Message-State: AOJu0Yx4B6veYrNXJ+uEO7PRDOS9+Zqe0BwEkjFRvuIsHFWQGyYAVHGt RCYqOHOODSPe90aeCmUjbzH1nOZUiymK0BPJAITaFbcgOODYa6PGrQztZaCpJXqsWgLoPruUNEB s X-Gm-Gg: ASbGncv2RLiLJDJx332OL105WESU4m+pxhUQO3SoqqMjervmQ8zBzwOcw7oaZYBkjjQ IAROy3578l80M2gslRMc5y7lpmGyxfOtGjiDvikKpLGoE25Tm2jGolxdWdWfBF5RaTJJ0P2b62j 5O+gCjzC+dbAByk4+qwzdnEVbtZbIEPvKWyLEt69UTmyc23DiGm68f0BMMG/OgMm6HUui7/VXpJ MQwPn3Cn+4PSic2gbdgWF93SFLxTf0LmEIQ325dnyliUZxy4pPfIF4ifL2e8RNiUmHnlQ== X-Google-Smtp-Source: AGHT+IGVtpgZLwqzBv1STerXMBG5F3Xv5KeJkgN+BsIiRzsnFO8C/jiKmuKjicONNJ0I6otqhuGAmA== X-Received: by 2002:a05:6402:520d:b0:5d9:ae5:8318 with SMTP id 4fb4d7f45d1cf-5d972e1da12mr61657177a12.20.1736878388840; Tue, 14 Jan 2025 10:13:08 -0800 (PST) Received: from localhost (109-81-90-202.rct.o2.cz. [109.81.90.202]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ab2c90d9ae0sm664853766b.68.2025.01.14.10.13.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jan 2025 10:13:08 -0800 (PST) Date: Tue, 14 Jan 2025 19:13:07 +0100 From: Michal Hocko To: Rik van Riel Cc: Johannes Weiner , Yosry Ahmed , Balbir Singh , Roman Gushchin , hakeel Butt , Muchun Song , Andrew Morton , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, Nhat Pham Subject: Re: [PATCH v2] memcg: allow exiting tasks to write back data to swap Message-ID: References: <20241212115754.38f798b3@fangorn> <20241212183012.GB1026@cmpxchg.org> <20250114160955.GA1115056@cmpxchg.org> <193d98b0d5d2b14da1b96953fcb5d91b2a35bf21.camel@surriel.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: <193d98b0d5d2b14da1b96953fcb5d91b2a35bf21.camel@surriel.com> On Tue 14-01-25 12:11:54, Rik van Riel wrote: > On Tue, 2025-01-14 at 18:00 +0100, Michal Hocko wrote: > > On Tue 14-01-25 11:51:18, Rik van Riel wrote: > > > On Tue, 2025-01-14 at 17:46 +0100, Michal Hocko wrote: > > > > On Tue 14-01-25 11:09:55, Johannes Weiner wrote: > > > > > > > > > charge_memcg > > > > > mem_cgroup_swapin_charge_folio > > > > > __read_swap_cache_async > > > > > swapin_readahead > > > > > do_swap_page > > > > > handle_mm_fault > > > > > do_user_addr_fault > > > > > exc_page_fault > > > > > asm_exc_page_fault > > > > > __get_user > > > > > > > > All the way here and return the failure to futex_cleanup which > > > > doesn't > > > > retry __get_user on the failure AFAICS (exit_robust_list). But I > > > > might > > > > be missing something, it's been quite some time since I've looked > > > > into > > > > futex code. > > > > > > Can you explain how -ENOMEM would get propagated down > > > past the page fault handler? > > > > > > This isn't get_user_pages(), which can just pass > > > -ENOMEM on to the caller. > > > > > > If there is code to pass -ENOMEM on past the page > > > fault exception handler, I have not been able to > > > find it. How does this work? > > > > This might be me misunderstading get_user machinery but doesn't it > > return a failure on PF handler returing ENOMEM? > > I believe __get_user simply does a memcpy, and ends > up in the page fault handler. It's been ages since I've looked into that code and my memory might be very rusty. But IIRC the page fault would be handled through exception table and return EFAULT on the failure. But I am not really sure whether that is the case for all errors returned by the page fault handler or only for SEGV/SIGBUS. I need to refresh my memory on that. Anyway, have you tried to reproduce with diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 7b3503d12aaf..9c30c442e3b0 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1627,7 +1627,7 @@ static bool mem_cgroup_out_of_memory(struct mem_cgroup *memcg, gfp_t gfp_mask, * A few threads which were not waiting at mutex_lock_killable() can * fail to bail out. Therefore, check again after holding oom_lock. */ - ret = task_is_dying() || out_of_memory(&oc); + ret = out_of_memory(&oc); unlock: mutex_unlock(&oom_lock); proposed by Johannes earlier? This should help to trigger the oom reaper to free up some memory. -- Michal Hocko SUSE Labs