Re: [PATCH 05/11] IB/hfi1: convert __mmu_int_rb to half closed intervals

From: Davidlohr Bueso <dave@stgolabs.net>
To: Michel Lespinasse <walken@google.com>
Cc: akpm@linux-foundation.org, peterz@infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	dri-devel@lists.freedesktop.org, linux-rdma@vger.kernel.org,
	Mike Marciniszyn <mike.marciniszyn@intel.com>,
	Dennis Dalessandro <dennis.dalessandro@intel.com>,
	Doug Ledford <dledford@redhat.com>,
	Davidlohr Bueso <dbueso@suse.de>
Subject: Re: [PATCH 05/11] IB/hfi1: convert __mmu_int_rb to half closed intervals
Date: Fri, 4 Oct 2019 12:41:11 -0700	[thread overview]
Message-ID: <20191004194111.2ntsr5kus5dgnnt4@linux-p48b> (raw)
In-Reply-To: <20191004115057.GA2371@google.com>

On Fri, 04 Oct 2019, Michel Lespinasse wrote:

>On Thu, Oct 03, 2019 at 01:18:52PM -0700, Davidlohr Bueso wrote:
>> diff --git a/drivers/infiniband/hw/hfi1/mmu_rb.c b/drivers/infiniband/hw/hfi1/mmu_rb.c
>> index 14d2a90964c3..fb6382b2d44e 100644
>> --- a/drivers/infiniband/hw/hfi1/mmu_rb.c
>> +++ b/drivers/infiniband/hw/hfi1/mmu_rb.c
>> @@ -47,7 +47,7 @@
>>  #include <linux/list.h>
>>  #include <linux/rculist.h>
>>  #include <linux/mmu_notifier.h>
>> -#include <linux/interval_tree_generic.h>
>> +#include <linux/interval_tree_gen.h>
>>
>>  #include "mmu_rb.h"
>>  #include "trace.h"
>> @@ -89,7 +89,7 @@ static unsigned long mmu_node_start(struct mmu_rb_node *node)
>>
>>  static unsigned long mmu_node_last(struct mmu_rb_node *node)
>>  {
>> -	return PAGE_ALIGN(node->addr + node->len) - 1;
>> +	return PAGE_ALIGN(node->addr + node->len);
>>  }
>
>May as well rename the function mmu_node_end(). I was worried if it
>was used anywhere else, but it turned out it's only used when defining
>the interval tree.

Right.

In general I tried not to rename everything to end because I wanted to
avoid bloating the diffstat, albeit having naming discrepancies within
the code (which isn't new either fwiw).

>
>I would also suggest moving this function (as well as mmu_node_first)
>right before its use, rather than just after, which would allow you to
>also remove the function prototype a few lines earlier.

Indeed, but again I don't want to unnecessarily grow the patch. I have
several notes to come back to once/if this series is settled.

>
>Looks good to me otherwise.
>
>Reviewed-by: Michel Lespinasse <walken@google.com>

Thanks,
Davidlohr