Re: [PATCH AUTOSEL 13/14] mm/thp: ClearPageDoubleMap in first page_add_file_rmap() - Greg Kroah-Hartman

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Hugh Dickins <hughd@google.com>
Cc: stable@vger.kernel.org, linux-kernel@vger.kernel.org,
	Yang Shi <shy828301@gmail.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-mm@kvack.org
Subject: Re: [PATCH AUTOSEL 13/14] mm/thp: ClearPageDoubleMap in first page_add_file_rmap()
Date: Thu, 28 Apr 2022 18:58:25 +0200	[thread overview]
Message-ID: <YmrHsVZTEzqIDiKd@kroah.com> (raw)
In-Reply-To: <c2ed1fe1-247e-e644-c367-87d32eb92cf5@google.com>

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 <hughd@google.com>
> > 
> > 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 <hughd@google.com>
> > Reviewed-by: Yang Shi <shy828301@gmail.com>
> > Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> 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.

True, this was my attempt at saying "hey these all look like they should
go to stable trees, why not?"

> I've chosen to answer to this patch of my 3 in your 14 AUTOSELs,
> because this one is just an improvement, not at all a bugfix needed
> for stable (maybe AUTOSEL noticed "racy" or "safely" in the comments,
> and misunderstood).  The "Fixes" was intended to help any humans who
> wanted to backport into their trees.

This all was off of the Fixes: tag.  Again, if these commits fix
something why are they not for stable?  I'm a human asking to backport
these into the stable trees based on that :)

> I do recall that this 13/14, and 14/14, are mods to mm/rmap.c
> which followed other (mm/munlock) mods to mm/rmap.c in 5.18-rc1,
> which affected the out path of the function involved, and somehow
> made 14/14 a little cleaner.  I'm sorry, but I just don't rate it
> worth my time at the moment, to verify whether 14/14 happens to
> have ended up as a correct patch or not.
> 
> And nobody can verify them without these AUTOSELs saying to which
> tree they are targeted - 5.17 I suppose.

5.17 to start with, older ones based on where the Fixes: tags went to.

So do you really want me to drop these?  I will but why are you adding
fixes: tags if you don't want people to take them?

thanks,

greg k-h