Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp937667pxb; Wed, 27 Oct 2021 15:37:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyjkucDW+vWiyBAVPR7SJzf8NvadpFIs5+rVEzHwCp06tpNd9NczNVRQu8PkKkIBos2APub X-Received: by 2002:a63:8bc1:: with SMTP id j184mr386782pge.385.1635374253009; Wed, 27 Oct 2021 15:37:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635374253; cv=none; d=google.com; s=arc-20160816; b=ZQ51MFfuhusSerAI6GhuhE4hoRzCWEEjxNx4Jna5F4yCvV3ZHMdqhr3iR5O942ZlcB csi+UZ/sllBctxKH6bkEYQGPaJzcOXIInR5EdTLl1Y9Tdo7K/kdhf5/3Xf0r9hZs5AIt 0FI94x29Y/YOzRLV9nVWIAQX2jG95ikE1nAnPNjJzC/Bpr4uUudwCJ8d7yUVnQtTeo8L oDuYNDkliKJh/iBf4W/d9ZtZiSiyl+IDx53DFV+XF/NycOji/BGn1+OfVLZf+f7oiPcs XM2cunvniwkgJWoAs85v60da27c8vugz0AAda6WWSyaikWc6jE/Vc+G9uNKxnDKfGr1G Qxwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=1V+1PW9d7mMsrvDbbFfYw5NdXmWkg6vmfoBMquK5C4Y=; b=VkY7QNIQkaFjxst+Oz00H9+LUS4eKN9PsN8Wy/BJ09rC7NLS6b41PVH8Ciymp3b7ra voikLwCmMI8xSCShi3H5lU0R4TPzfSxxf9VFkBmovXUmFCmK4405CP866NvmB94tJp/t wM4x8E5EBy98G9M06g5iZqbsdnEcGQat+GevAZ8nLWdcVCrhG9F/DWWMxCHqbHtXJgGy e3xtjEK6QMt6VuQzN2+w/Hh2imcmlGIIy10geHgMMitqsJzNa336WUwJCNZiZPGtgAOA yFDv2v1KXl5lvQ7yfHLXag9aq55KXht6FwD1WHzNW/tE4JbGGVJGifHhIPQMvGh4Xcjy MWiA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=voGDb2zX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w11si1619888plg.369.2021.10.27.15.37.20; Wed, 27 Oct 2021 15:37:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=voGDb2zX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229863AbhJ0Wih (ORCPT + 99 others); Wed, 27 Oct 2021 18:38:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:54598 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229484AbhJ0Wig (ORCPT ); Wed, 27 Oct 2021 18:38:36 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id D0F29610CB; Wed, 27 Oct 2021 22:36:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1635374170; bh=zeRXlf3fAzntvGnBMpDwMgonqEP9pBriRbcBLNzhnE8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=voGDb2zXrSVNrVTxvYv+5pMhCPRA3F8fwGVSJ7e4sGicSa89iz8fbmPQ5IDUj6bbB /7BX5p6IZvMH1BZP+4LX56HqXYw5bE76pXVRLoi98OHqHA5a8vD16kOneRNlBRbsGG uykElR9RFUVO+G11QXqJr8RFcQrPCNZlTWAsud4Q= Date: Wed, 27 Oct 2021 15:36:08 -0700 From: Andrew Morton To: Michal Hocko Cc: Vasily Averin , Johannes Weiner , Vladimir Davydov , Roman Gushchin , Uladzislau Rezki , Vlastimil Babka , Shakeel Butt , Mel Gorman , Tetsuo Handa , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel@openvz.org, Greg Kroah-Hartman Subject: Re: [PATCH memcg v3 3/3] memcg: prohibit unconditional exceeding the limit of dying tasks Message-Id: <20211027153608.9910f7db99d5ef574045370e@linux-foundation.org> In-Reply-To: References: <8f5cebbb-06da-4902-91f0-6566fc4b4203@virtuozzo.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 25 Oct 2021 11:36:41 +0200 Michal Hocko wrote: > My view on stable backport is similar to the previous patch. If we want > to have it there then let's wait for some time to see whether there are > any fallouts as this patch depends on the PF_OOM change. It's strange that [1/3] doesn't have cc:stable, but [2/3] and [3/3] do not. What is the thinking here? I expect we'd be OK with merging these into 5.16-rc1. This still gives another couple of months in -rc to shake out any problems. But I suspect the -stable maintainers will merge and release the patches before they are released in 5.16. In which case an alternative would be not to mark these patches cc:stable and to somehow remember to ask the -stable maintainers to merge them after 5.16 has been on the streets for a suitable period. Greg, thoughts?