Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp771147pxv; Wed, 14 Jul 2021 15:21:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzeNE1RFVVQV3c5zVR911x4UoQgtFLAHwdEk4T4ncfImCexYRHcNOtJybEe1gaiCfSmp2ZQ X-Received: by 2002:a05:6602:d9:: with SMTP id z25mr280071ioe.154.1626301308656; Wed, 14 Jul 2021 15:21:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626301308; cv=none; d=google.com; s=arc-20160816; b=RkDV3D//npyvlMARFwIZqrtnHB+yBznWz1zMnUJgg3sdGD6N82BIAGAXjNSd+ubanE 76zH6KMEbT09R0kYc+/wmVeQURVynD6O2LJc/AG7y0KQwP5rAuQGxpGg1rn8pR45XR1f Yr08Dt20XBynkQs5XqrHC6d/tuQ6MP8wdWqoPzMSxGX+hiHGQfroAxeIrjGn8BtuUTa9 vzVo46BPz/HxDTM84WmfCAtlsrx3CU7cUfRZvZjo+835MSdFwzoxS1JtCxWCGGzr3xup HTEz+lKdWPlqm0qODWRfaLhdnXfKIPEJH1d1ERVmvSKzfmci1LTlg0CT0Oy5aiD89iYS OW9w== 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=9bHJ75saa2EWZy8prruLgkXnboMieuvSOvHo0lsND9Y=; b=snwirUS9TWeI4C512Nq5uR2onx0LzoaqLy5Nh+AGGZam85UrIW6lUANk/up9jsZXjJ JoWLF4I4tPeuYAjVoKAG+T4Dqd1gwvK8Ra5/dnFjbmCgq6bSHRrTDL838WVM8G7FYXt+ e4AgJc7tLXc1kS2q3BZA38p/L83CYvHWYTEivubM+PBOR3nJ8RO3nZ5mNUMir0BkQhUg 1u5InT/5D/EDL8dpfVTPBMLWTXxUtHjc1PbuVOe4sSjupQed0EqAMf3Q41MIT/zPo7Yw LR0q5sHqXsc/lAlSsO/QVO1M2as73w9lZc4328kcCo2IoezvYAFA5roPz4JsdZTuDiO1 hjeA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b="y44sm/Pm"; 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 f7si1653664jat.42.2021.07.14.15.21.34; Wed, 14 Jul 2021 15:21:48 -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="y44sm/Pm"; 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 S235225AbhGNVMH (ORCPT + 99 others); Wed, 14 Jul 2021 17:12:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:58756 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234998AbhGNVME (ORCPT ); Wed, 14 Jul 2021 17:12:04 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id B46BF613CC; Wed, 14 Jul 2021 21:09:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1626296952; bh=hHlXOWAlgpR5zYXZWRZLzEhjTkhsaaifQTA1+gqRSu4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=y44sm/PmDvlcm+SYUSSbjyrMdahlB1dXzuDoxpGIElSAhhuyE/IxYd8wq7baRA0Sk HNL7tgdBEaKQOd/hZSXZsY9cGjpHhqQ7x9qLAjaLew4dlqO+y7G4fKolAExtHlUI3w R3zDLSDN9Ash9MzS9pVhT547n9ygj/6rb7PJraZg= Date: Wed, 14 Jul 2021 14:09:11 -0700 From: Andrew Morton To: Greg Kroah-Hartman Cc: Sasha Levin , Michal Hocko , Hugh Dickins , Linus Torvalds , Mike Kravetz , Miaohe Lin , linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org Subject: Re: 5.13.2-rc and others have many not for stable Message-Id: <20210714140911.6c45f8f4a9b129ed36bb9d06@linux-foundation.org> In-Reply-To: References: <2b1b798e-8449-11e-e2a1-daf6a341409b@google.com> <20210713182813.2fdd57075a732c229f901140@linux-foundation.org> 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 Wed, 14 Jul 2021 15:23:50 +0200 Greg Kroah-Hartman wrote: > > But it really feels odd that you all take the time to add a "Hey, this > > fixes this specific commit!" tag in the changelog, yet you do not > > actually want to go and fix the kernels that have that commit in it. > > This is an odd signal to others that watch the changelogs for context > > clues. Perhaps you might not want to do that anymore. > > I looked at some of these patches and it seems really odd to me that you > all are marking them with Fixes: tags, but do not want them backported. > > First example is babbbdd08af9 ("mm/huge_memory.c: don't discard hugepage > if other processes are mapping it") > > Why is this not ok to backport? > > Also what about e6be37b2e7bd ("mm/huge_memory.c: add missing read-only > THP checking in transparent_hugepage_enabled()")? > > And 41eb5df1cbc9 ("mm: memcg/slab: properly set up gfp flags for objcg > pointer array")? > > And 6acfb5ba150c ("mm: migrate: fix missing update page_private to > hugetlb_page_subpool")? > > And 832b50725373 ("mm: mmap_lock: use local locks instead of disabling > preemption")? (the RT people want that...) > > And f7ec104458e0 ("mm/page_alloc: fix counting of managed_pages")? > > Do you want to rely on systems where these fixes are not applied? > > I can understand if you all want to send them to us later after they > have been "tested out" in Linus's tree, that's fine, but to just not > want them applied at all feels odd to me. Broadly speaking: end-user impact. If we don't have reports of the issue causing a user-visible problem and we don't expect such things to occur, don't backport. Why risk causing some regression when we cannot identify any benefit? (and boy do my fingers get tired asking people to describe the user-visible effects of the bug they claim to have fixed!) Of course, screwups can happen and user-useful patches may be passed over.