Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755239AbcKVEbJ (ORCPT ); Mon, 21 Nov 2016 23:31:09 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:47596 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755124AbcKVEbI (ORCPT ); Mon, 21 Nov 2016 23:31:08 -0500 Subject: Re: [HMM v13 03/18] mm/ZONE_DEVICE/free_hot_cold_page: catch ZONE_DEVICE pages To: Jerome Glisse References: <1479493107-982-1-git-send-email-jglisse@redhat.com> <1479493107-982-4-git-send-email-jglisse@redhat.com> <5832ADD2.5000507@linux.vnet.ibm.com> <20161121125029.GG2392@redhat.com> Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, John Hubbard , Dan Williams , Ross Zwisler From: Anshuman Khandual Date: Tue, 22 Nov 2016 10:00:54 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20161121125029.GG2392@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16112204-0040-0000-0000-000002CA2E1F X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16112204-0041-0000-0000-00000BBCACE5 Message-Id: <5833C9FE.4030506@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-22_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611220080 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1821 Lines: 45 On 11/21/2016 06:20 PM, Jerome Glisse wrote: > On Mon, Nov 21, 2016 at 01:48:26PM +0530, Anshuman Khandual wrote: >> On 11/18/2016 11:48 PM, J?r?me Glisse wrote: >>> Catch page from ZONE_DEVICE in free_hot_cold_page(). This should never >>> happen as ZONE_DEVICE page must always have an elevated refcount. >>> >>> This is to catch refcounting issues in a sane way for ZONE_DEVICE pages. >>> >>> Signed-off-by: J?r?me Glisse >>> Cc: Dan Williams >>> Cc: Ross Zwisler >>> --- >>> mm/page_alloc.c | 10 ++++++++++ >>> 1 file changed, 10 insertions(+) >>> >>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >>> index 0fbfead..09b2630 100644 >>> --- a/mm/page_alloc.c >>> +++ b/mm/page_alloc.c >>> @@ -2435,6 +2435,16 @@ void free_hot_cold_page(struct page *page, bool cold) >>> unsigned long pfn = page_to_pfn(page); >>> int migratetype; >>> >>> + /* >>> + * This should never happen ! Page from ZONE_DEVICE always must have an >>> + * active refcount. Complain about it and try to restore the refcount. >>> + */ >>> + if (is_zone_device_page(page)) { >>> + VM_BUG_ON_PAGE(is_zone_device_page(page), page); >>> + page_ref_inc(page); >>> + return; >>> + } >> >> This fixes an issue in the existing ZONE_DEVICE code, should not this >> patch be sent separately not in this series ? >> > > Well this is more like a safetynet feature, i can send it separately from the > series. It is not an issue per say as a trap to catch bugs. I had refcounting > bugs while working on this patchset and having this safetynet was helpful to > quickly pin-point issues. Sure at the least move them up in the series as ZONE_DEVICE preparatory fixes before expanding ZONE_DEVICE framework to accommodate the new un-addressable memory representation.