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.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 8A2F9C32792 for ; Thu, 3 Oct 2019 20:32:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4E59C207FF for ; Thu, 3 Oct 2019 20:32:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="RYxhot7m" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4E59C207FF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D891A6B0006; Thu, 3 Oct 2019 16:32:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D39BB6B0007; Thu, 3 Oct 2019 16:32:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C50048E0003; Thu, 3 Oct 2019 16:32:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0180.hostedemail.com [216.40.44.180]) by kanga.kvack.org (Postfix) with ESMTP id A34326B0006 for ; Thu, 3 Oct 2019 16:32:57 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 407838406 for ; Thu, 3 Oct 2019 20:32:57 +0000 (UTC) X-FDA: 76003622394.29.cow41_7105046d07e56 X-HE-Tag: cow41_7105046d07e56 X-Filterd-Recvd-Size: 2906 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf23.hostedemail.com (Postfix) with ESMTP for ; Thu, 3 Oct 2019 20:32:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DuwMGQIzbvieUCH04dpyi9AiTx6jv704Pfn5oVeJ17U=; b=RYxhot7mP0JyjcYaAZEScfO1B 6EJMyUWXlNdT3UDcTvRnHCNreWLXGGY7iNXJWyn8XMRiBWuyKwXKAiNt97SK5zlHmjecIp1vV4QWf 3MMmDQuoXudCRIc3Pntnzk2D+nvYpA8R+DX19eIvAyEP60ti312vCUTZKPIKYOvqoGA7oPhRxWmsb 1wYUz+J1z5n5H4HBkA3jKBidq9Notx4vPfLBTylntN2b7ob3ZWf6Kqj8qAvdy6F2hUPeIbiIPuwzR 7gp1Xw/1/mREnXHy2ysx3SPtsTRHHROdIH4BPHiovRiPo+t+ICndCH/x22GYqYbq3CHBGXVgVRR/X UqAc4SSkg==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.2 #3 (Red Hat Linux)) id 1iG7mM-0006xH-SJ; Thu, 03 Oct 2019 20:32:50 +0000 Date: Thu, 3 Oct 2019 13:32:50 -0700 From: Matthew Wilcox To: Davidlohr Bueso 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 Subject: Re: [PATCH -next 00/11] lib/interval-tree: move to half closed intervals Message-ID: <20191003203250.GE32665@bombadil.infradead.org> References: <20191003201858.11666-1-dave@stgolabs.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191003201858.11666-1-dave@stgolabs.net> User-Agent: Mutt/1.12.1 (2019-06-15) 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 Thu, Oct 03, 2019 at 01:18:47PM -0700, Davidlohr Bueso wrote: > It has been discussed[1,2] that almost all users of interval trees would better > be served if the intervals were actually not [a,b], but instead [a, b). This So how does a user represent a range from ULONG_MAX to ULONG_MAX now? I think the problem is that large parts of the kernel just don't consider integer overflow. Because we write in C, it's natural to write: for (i = start; i < end; i++) and just assume that we never need to hit ULONG_MAX or UINT_MAX. If we're storing addresses, that's generally true -- most architectures don't allow addresses in the -PAGE_SIZE to ULONG_MAX range (or they'd have trouble with PTR_ERR). If you're looking at file sizes, that's not true on 32-bit machines, and we've definitely seen filesystem bugs with files nudging up on 16TB (on 32 bit with 4k page size). Or block driver bugs with similarly sized block devices. So, yeah, easier to use. But damning corner cases.