From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753982AbbLVRUX (ORCPT <rfc822;w@1wt.eu>);
	Tue, 22 Dec 2015 12:20:23 -0500
Received: from g9t5008.houston.hp.com ([15.240.92.66]:57765 "EHLO
	g9t5008.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751615AbbLVRUW (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 22 Dec 2015 12:20:22 -0500
Message-ID: <1450804798.10450.45.camel@hpe.com>
Subject: Re: [PATCH 2/2] x86/mm/pat: Change free_memtype() to free shrinking
 range
From: Toshi Kani <toshi.kani@hpe.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: mingo@redhat.com, hpa@zytor.com, bp@alien8.de, stsp@list.ru,
        x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Borislav Petkov <bp@suse.de>
Date: Tue, 22 Dec 2015 10:19:58 -0700
In-Reply-To: <alpine.DEB.2.11.1512201025050.28591@nanos>
References: <1449678368-31793-1-git-send-email-toshi.kani@hpe.com>
	 <1449678368-31793-3-git-send-email-toshi.kani@hpe.com>
	 <alpine.DEB.2.11.1512201025050.28591@nanos>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.16.5 (3.16.5-3.fc22) 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, 2015-12-20 at 10:27 +0100, Thomas Gleixner wrote:
> Toshi,
> 
> On Wed, 9 Dec 2015, Toshi Kani wrote:
> > diff --git a/arch/x86/mm/pat_rbtree.c b/arch/x86/mm/pat_rbtree.c
> > index 6393108..d6faef8 100644
> > --- a/arch/x86/mm/pat_rbtree.c
> > +++ b/arch/x86/mm/pat_rbtree.c
> > @@ -107,7 +112,12 @@ static struct memtype
> > *memtype_rb_exact_match(struct rb_root *root,
> >  	while (match != NULL && match->start < end) {
> >  		struct rb_node *node;
> >  
> > -		if (match->start == start && match->end == end)
> > +		if ((match_type == MEMTYPE_EXACT_MATCH) &&
> > +		    (match->start == start) && (match->end == end))
> > +			return match;
> > +
> > +		if ((match_type == MEMTYPE_SHRINK_MATCH) &&
> > +		    (match->start < start) && (match->end == end))
> 
> Confused. If we shrink a mapping then I'd expect that the start of the
> mapping stays the same and the end changes. 

Yes, that is correct after this request is done.

> I certainly miss something here, but if the above is correct, then it 
> definitely needs a big fat comment explaining it.

This request specifies a range being "unmapped", not the remaining mapped
range.  So, when the mapping range is going to shrink from the end, the
unmapping range has a bigger 'start' value and the same 'end' value. 

Thanks,
-Toshi