From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michel Lespinasse Subject: Re: [PATCH 08/11] mm: convert vma_interval_tree to half closed intervals Date: Fri, 4 Oct 2019 05:30:44 -0700 Message-ID: <20191004123044.GA11046@google.com> References: <20191003201858.11666-1-dave@stgolabs.net> <20191003201858.11666-9-dave@stgolabs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20191003201858.11666-9-dave@stgolabs.net> Sender: linux-kernel-owner@vger.kernel.org To: Davidlohr Bueso , Matthew Wilcox 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, Davidlohr Bueso List-Id: dri-devel@lists.freedesktop.org On Thu, Oct 03, 2019 at 01:18:55PM -0700, Davidlohr Bueso wrote: > The vma and anon vma interval tree really wants [a, b) intervals, > not fully closed. As such convert it to use the new > interval_tree_gen.h. Because of vma_last_pgoff(), the conversion > is quite straightforward. I am not certain if we need to worry about integer overflow here. The problem case would be accessing the last block of a file that is exactly 16TB long, on an arch where long (and thus pgoff_t) is 32-bit. Maybe FS folks can tell us whether that case is currently supported, or if we can just not worry about it ? I would also want to rename the fields in struct zap_details into start_index and end_index so we can verify we don't leave any off-by-one uses. -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies.