From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 93EE0C433F5 for ; Sat, 30 Apr 2022 00:27:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F0B1C6B0072; Fri, 29 Apr 2022 20:27:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EB89D6B0073; Fri, 29 Apr 2022 20:27:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D81CE6B0074; Fri, 29 Apr 2022 20:27:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id CA05A6B0072 for ; Fri, 29 Apr 2022 20:27:06 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 8F3FD80B8D for ; Sat, 30 Apr 2022 00:27:06 +0000 (UTC) X-FDA: 79411655652.20.3DC2FD1 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf11.hostedemail.com (Postfix) with ESMTP id CD1554001F for ; Sat, 30 Apr 2022 00:27:02 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1AC596243B; Sat, 30 Apr 2022 00:27:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 38725C385A4; Sat, 30 Apr 2022 00:27:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651278424; bh=ZY6lCWFeGbK7gENJJ1vDCLA1WWWMx/zm0VeDflagIBE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Ygg6MGVn6QSNdq7kp3gNjqQmB+hnOtu40Z295SdnBj8b75mTmT4cr+r2YS65ZT3rd G85xL5kf/tgTwTbGOK0yKXWvvfL626D4+JyJFG7BlhxefUxwPXnBdQqjiU6bdnQhlv xrEKvbOn7h4TBnueU2Y8KeCWjl9AcDNX+nPEDnoyEoG3fC9fNzU1YS3hBnWkpwdzG7 JwPTSfNJhd9BQFcbkA7+jW6xCz/c/7FhJx5ucds7cClGkvIb2dikZzB4mbSmSuO1+g izzp+WcjjDqOyDFr4wkxBW3ptbeejChEpyT/Cr33bUHUXLUwmbNqY2wZOSW9SSmnBO nnq9v9yYi4zTQ== Date: Fri, 29 Apr 2022 20:27:02 -0400 From: Sasha Levin To: Hugh Dickins Cc: Greg Kroah-Hartman , stable@vger.kernel.org, linux-kernel@vger.kernel.org, Yang Shi , "Kirill A. Shutemov" , Andrew Morton , Linus Torvalds , linux-mm@kvack.org Subject: Re: [PATCH AUTOSEL 13/14] mm/thp: ClearPageDoubleMap in first page_add_file_rmap() Message-ID: References: <20220428154222.1230793-1-gregkh@linuxfoundation.org> <20220428154222.1230793-13-gregkh@linuxfoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: CD1554001F X-Stat-Signature: 3bihw8qoehhk5653wyw8zsoarn1rjsu7 Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Ygg6MGVn; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf11.hostedemail.com: domain of sashal@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sashal@kernel.org X-Rspam-User: X-HE-Tag: 1651278422-411838 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Apr 28, 2022 at 12:27:40PM -0700, Hugh Dickins wrote: >On Thu, 28 Apr 2022, Greg Kroah-Hartman wrote: >> On Thu, Apr 28, 2022 at 09:51:58AM -0700, Hugh Dickins wrote: >> > On Thu, 28 Apr 2022, Greg Kroah-Hartman wrote: >> > >> > > From: Hugh Dickins >> > > >> > > commit bd55b0c2d64e84a75575f548a33a3dfecc135b65 upstream. >> > > >> > > PageDoubleMap is maintained differently for anon and for shmem+file: the >> > > shmem+file one was never cleared, because a safe place to do so could >> > > not be found; so it would blight future use of the cached hugepage until >> > > evicted. >> > > >> > > See https://lore.kernel.org/lkml/1571938066-29031-1-git-send-email-yang.shi@linux.alibaba.com/ >> > > >> > > But page_add_file_rmap() does provide a safe place to do so (though later >> > > than one might wish): allowing testing to return to an initial state >> > > without a damaging drop_caches. >> > > >> > > Link: https://lkml.kernel.org/r/61c5cf99-a962-9a25-597a-53ab1bd8fbc0@google.com >> > > Fixes: 9a73f61bdb8a ("thp, mlock: do not mlock PTE-mapped file huge pages") >> > > Signed-off-by: Hugh Dickins >> > > Reviewed-by: Yang Shi >> > > Cc: "Kirill A. Shutemov" >> > > Signed-off-by: Andrew Morton >> > > Signed-off-by: Linus Torvalds >> > > Signed-off-by: Greg Kroah-Hartman >> > >> > NAK. >> > >> > I thought we had a long-standing agreement that AUTOSEL does not try >> > to add patches from akpm's tree which had not been marked for stable. I guess it was only between myself and mm/ :p >> True, this was my attempt at saying "hey these all look like they should >> go to stable trees, why not?" > >Okay, it seems I should have read "AUTOSEL" as "Hey, GregKH here, >these all look like they should go to stable trees, why not?", >which would have drawn a friendlier response. FRIENDLYGREGBOT :) >The answer is that I considered stable at the time, and akpm did too, >and none of my three (I've not looked through the other 11) are serious >enough to be needed in stable; and I'm cautious about backports, because >I know that the tree they went on top of differs thereabouts from 5.17. > >Of course I think the patches in 5.18-rc are good, and yes, they're >things I've thought worthwhile enough for me personally to port forward >over several releases until I had time to send in. But that doesn't >make them safe stable candidates, without someone to verify and vouch >for the results in this or that tree - I run on a much slower clock >than you and most around here, I do not have time for that at present >(and would prefer not even to be having this conversation). > >But I'm happily overruled if any mm guys think they are worth that >extra effort, and will verify and vouch for them. What's the extra effort here? We're seeing so many cases where we see issues with LTS kernels and we end up spending so much time triaging and diagnosing them only to find out that they've already been fixed. Honesly, having them in -stable seems like *less* effort to me. -- Thanks, Sasha