From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outbound-smtp09.blacknight.com ([46.22.139.14]:60485 "EHLO outbound-smtp09.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934834AbdEZPlV (ORCPT ); Fri, 26 May 2017 11:41:21 -0400 Received: from mail.blacknight.com (pemlinmail06.blacknight.ie [81.17.255.152]) by outbound-smtp09.blacknight.com (Postfix) with ESMTPS id A01D11C297C for ; Fri, 26 May 2017 16:33:03 +0100 (IST) Date: Fri, 26 May 2017 16:33:02 +0100 From: Mel Gorman To: Punit Agrawal Cc: akpm@linux-foundation.org, cl@linux.com, iamjoonsoo.kim@lge.com, manoj.iyer@canonical.com, n-horiguchi@ah.jp.nec.com, stable@vger.kernel.org, wanpeng.li@hotmail.com, mm-commits@vger.kernel.org Subject: Re: + mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch added to -mm tree Message-ID: <20170526153302.3n3v4rzajx5dkzdq@techsingularity.net> References: <59275ebf.J2Z9kk9uuHWKdJS8%akpm@linux-foundation.org> <20170526104239.d2dwmm3vdcjx2g5n@techsingularity.net> <87bmqfd61m.fsf@e105922-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <87bmqfd61m.fsf@e105922-lin.cambridge.arm.com> Sender: stable-owner@vger.kernel.org List-ID: On Fri, May 26, 2017 at 03:52:21PM +0100, Punit Agrawal wrote: > > I've never looked too closely at how hardware poisoning and hugetlb pages > > migration is handled so I could easily have missed something but this > > changelog and patch confuses me. > > > > Surely if the inconsistency is between hugepage_migration_supported and > > !hugepage_migration_supported then the check in soft_offline_huge_page() > > should also be related to hugepage_migration_supported either in > > soft_offline_huge_page() or in putback_movable_pages()? > > The first version of the patch did indeed make a change that was around > !hugepage_migration_supported() [0] which was effectively a revert of > 32665f2bbfed ("mm/migrate: correct failure handling if > !hugepage_migration_support()"). > > But Horiguchi-san suggested that dropping the putback_active_hugepage() > from unmap_and_move_hugepage() will bring back the issue that > 32665f2bbfed addressed it was safer to take the current approach. It > also matches the pattern followed for !hugepage. > > I did update the changelog but perhaps not enough - would updating the > changelog to reflect this help make it clearer? > Ok, I see what the patch is doing now. I don't think you need to alter the changelog as I think the patch is ok. Thanks for clarifying. -- Mel Gorman SUSE Labs