From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) (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 A1D011AA1DC for ; Tue, 14 Jan 2025 17:01:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736874064; cv=none; b=Rm16x3/KfuFjVl+MWoN1eViWBwh8OklO3qOMhl3te0+fJ7uJdzSr/qkXc16K7MdjI7XqbJrcYWQjVATSs4LTByNY9uBjZa+7sUxhp/k+Kag6aAmYFPEGt2yXZomIrRxfwUum22YASzPulhP/mVbH66+XKX3ZK0o3M1NwNgpcdEo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736874064; c=relaxed/simple; bh=YJg4n6bu0eMo7z3f+6I5T+x9HeNtHJi9Sys/+7t7R64=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oyJLog3UcILdGg5f4G5uL7cKdLFqMFq2DVdpBUgiGFWLyqpyb7Pkzk76fyUYNKWJiVy4h55dZ4zeOTar/Cx/YrNshrkAmUAfJdiQZZ2UFN4CHOoCD+rdRKAmbihXNlVg76M3r1BKDDIu5gwkE+53iTw1/SV7pjGZmezGSGm7W2Y= 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=FUMf1qKD; arc=none smtp.client-ip=209.85.208.43 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="FUMf1qKD" Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-5d3d143376dso8238080a12.3 for ; Tue, 14 Jan 2025 09:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1736874061; x=1737478861; 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=PUoI2EyKt/knlrGvqwIP6n1ZeNaysEcJuerUgijRn1Q=; b=FUMf1qKDgYSZ/oMiCZELa3jNT4STd2QM+jbynpNFHDdhChjO3Y5S0ACYRrMWEerwUD aQx9cYbXL3dvkcbvk8T6U5eaX+6sQI/UYJND4sFOJi7pCIf8gBZEx5H4pwUN6Bh3I33V a56K1O1GB15ggmd9tVxotbTH36gKNc2+ZaI51UFvA3DSqLFSU2A5FchG6/GB4riGCyOV nJHpuByepekPma/dwVxmiP/ONI462M7Npvk8dQ0GbleMNyqLNp2cTAi8fWi/PcYpETN/ Eq9tNyewU3drXNUrdbB6GtGLSMDEmCkBxRhme0Qb5fqi7pvJJgVXt6lfgnzGstapcY0H SW8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736874061; x=1737478861; 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=PUoI2EyKt/knlrGvqwIP6n1ZeNaysEcJuerUgijRn1Q=; b=Gqjr3Ps69yfua91iXfgAw2OyNAF62xsL/YGwt7+HViLRMX35L1R0hhwP045Rn5qaEU hmsP8hJoc6s86wRzDGlXm276RQrLRj8m21gOirgHGnM2dYsRrFtMpjEPSLroPOsectZN GSEptcYa7pmzATb4ee/+I/T2sqFTF9zBuVA6vY8Kuzv5Y/04t8lepsez1nolcGt73Rkr 8YF16ejZddqzIZOhYXZo13eXqhw6DiMfGwjaIFyIpOBigFiYafqEkWrOr4tvv27NOtST ye5MtJny7nzMMoBPGHmaAT0X38ZJAhe5xwZy/nddSlT+dZp78Q3whozz3eWnA2ajdDf1 lebQ== X-Forwarded-Encrypted: i=1; AJvYcCW2tnnPs+YgqxvD/3El03ZN19YxMbJp9zErmg46sqHnHo5FoJkX7hwQp4zlZwcNeW7BFindAjfxj0pMF7s=@vger.kernel.org X-Gm-Message-State: AOJu0YyijUJ8XgP1NYB4nzucKDHkKOCJwjXyA8LQ/pOTXA1zjd8V8+B0 +4ry8PTidnHk0noF5TJWI5kcCVPZpBA/9eYzudopHHRh5BtV/oUvyDNe4V1//kQ= X-Gm-Gg: ASbGnctzvXam5V/tZ5Wpa/jQ5PveLlryHTaKmFBhd/POyTbVEDO0p3L17yQ1eepxCHB XeK2zW1Bd3LAvA8eiNzCRyWqwg6TJzP1QZ43gv0gOxKaN1o4YOM4kvwao3ihMBLBmgFNDr/pbjm 7RTkiswAQ1KlrwUisqYE/MgKBFtjm8hBAH1UgO6uy/8f/MWuBt4F6EedsuGCGjwEsDYGEJO0/3i W7kkhaqS1WGkfYHSgdeMcGhU2QJLrJ/AE44LjuqaIziSfu9qtTk2LGBslTarehRQjQU5A== X-Google-Smtp-Source: AGHT+IFlsRdDjUfkFl69+IV4zPFF4B9GZCFDetrBcvlk1aTeSGtQUB5pfsswDlESXqm2+oa8lB9xPQ== X-Received: by 2002:a05:6402:358c:b0:5d0:d84c:abb3 with SMTP id 4fb4d7f45d1cf-5d972e4c9a7mr22660785a12.26.1736874058860; Tue, 14 Jan 2025 09:00:58 -0800 (PST) Received: from localhost (109-81-90-202.rct.o2.cz. [109.81.90.202]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d99046dbe0sm6202402a12.64.2025.01.14.09.00.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jan 2025 09:00:58 -0800 (PST) Date: Tue, 14 Jan 2025 18:00:57 +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> 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 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: > > > > > > > > We managed to extract a stack trace of the livelocked task: > > > > > > obj_cgroup_may_swap > > > zswap_store > > > swap_writepage > > > shrink_folio_list > > > shrink_lruvec > > > shrink_node > > > do_try_to_free_pages > > > try_to_free_mem_cgroup_pages > > > > OK, so this is the reclaim path and it fails due to reasons you > > mention > > below. This will retry several times until it hits mem_cgroup_oom > > which > > will bail in mem_cgroup_out_of_memory because of task_is_dying > > (returns > > true) and retry the charge + reclaim (as the oom killer hasn't done > > anything) with passed_oom = true this time and eventually got to > > nomem > > path and returns ENOMEM. This should propaged -ENOMEM down the path > > > > > 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? -- Michal Hocko SUSE Labs