From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AFFB0C10F14 for ; Tue, 8 Oct 2019 17:00:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7154C21835 for ; Tue, 8 Oct 2019 17:00:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7154C21835 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=stgolabs.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1A1848E0005; Tue, 8 Oct 2019 13:00:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1527B8E0003; Tue, 8 Oct 2019 13:00:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 040F18E0005; Tue, 8 Oct 2019 13:00:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0023.hostedemail.com [216.40.44.23]) by kanga.kvack.org (Postfix) with ESMTP id D6EEB8E0003 for ; Tue, 8 Oct 2019 13:00:58 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 9595655F8A for ; Tue, 8 Oct 2019 17:00:58 +0000 (UTC) X-FDA: 76021232196.27.heart27_87487c9b531e X-HE-Tag: heart27_87487c9b531e X-Filterd-Recvd-Size: 3783 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Tue, 8 Oct 2019 17:00:57 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 6F213B1FF; Tue, 8 Oct 2019 17:00:56 +0000 (UTC) Date: Tue, 8 Oct 2019 09:59:42 -0700 From: Davidlohr Bueso To: "Koenig, Christian" Cc: "akpm@linux-foundation.org" , "walken@google.com" , "peterz@infradead.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "dri-devel@lists.freedesktop.org" , "linux-rdma@vger.kernel.org" , "Deucher, Alexander" , David Airlie , Daniel Vetter , Doug Ledford , Joerg Roedel , J?r?me Glisse , Davidlohr Bueso Subject: Re: [PATCH 09/11] lib/interval-tree: convert interval_tree to half closed intervals Message-ID: <20191008165942.vxfwbectycuersdx@linux-p48b> Mail-Followup-To: "Koenig, Christian" , "akpm@linux-foundation.org" , "walken@google.com" , "peterz@infradead.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "dri-devel@lists.freedesktop.org" , "linux-rdma@vger.kernel.org" , "Deucher, Alexander" , David Airlie , Daniel Vetter , Doug Ledford , Joerg Roedel , J?r?me Glisse , Davidlohr Bueso References: <20191003201858.11666-1-dave@stgolabs.net> <20191003201858.11666-10-dave@stgolabs.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: NeoMutt/20180716 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 04 Oct 2019, Koenig, Christian wrote: >Am 04.10.19 um 08:57 schrieb Christian K=F6nig: >> Am 03.10.19 um 22:18 schrieb Davidlohr Bueso: >>> The generic tree tree really wants [a, b) intervals, not fully closed. >>> As such convert it to use the new interval_tree_gen.h. Most of the >>> conversions are straightforward, with the exception of perhaps >>> radeon_vm_bo_set_addr(), but semantics have been tried to be left >>> untouched. >> >> NAK, the whole thing won't work. >> >> See we need to handle the full device address space which means we >> have values in the range of 0x0-0xffffffff. >> >> If you make this a closed interval then the end would wrap around to >> 0x0 if long is only 32bit. > >Well I've just now re-read the subject line. From that it sounds like >you are actually trying to fix the interval tree to use a half closed >interval, e.g. something like [a, b[ Correct. > >But your code changes sometimes doesn't seem to reflect that. Hmm the change simply aims at avoiding the end - 1 trick when dealing with interval_tree insertions and lookups; the rest of the series converts other interval tree users in a similar way, albeit some errors which will be updated. What are your concerns about this patch? Thanks, Davidlohr