Received: by 2002:ac0:da4c:0:0:0:0:0 with SMTP id a12csp477311imi; Fri, 22 Jul 2022 03:16:20 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sSza4hd00qgMHj5gmH0SnqwK/6G1ZdVV4NYZKxjfipkzJ4EZz+fH+OCjAzGKv+p4xG/aOM X-Received: by 2002:a17:907:2855:b0:72b:700e:21eb with SMTP id el21-20020a170907285500b0072b700e21ebmr2603915ejc.270.1658484980466; Fri, 22 Jul 2022 03:16:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658484980; cv=none; d=google.com; s=arc-20160816; b=QFdNu5dcSsmxoqpg8YPel/Vw9Da13cLltcHeAhJnG8UG0uXuFgp/9NOW9JRvSFvrjC C80EUqawjBrBcqwUZIRMUDmzWqUXZz3/ddHV2ZaMrx3Sa1wzKC2wvQyjbnqanTI8Y9iI iPLNEDMDIqmSEeLuDxNO6g/AtnkJ+a8zwKuGvmT0Gl2hoMZWKiUrMCAMisx/5Dvlgq4G KtaZZ8/7Kh6vEzEGX3clfdZZGW3X/8RIY38cgEaBidkVr7MrEQ9jy498ZGLBFHq3R7Ls EcsalF4HMAPPX+0NGFNQgNmF1v4k3/jSW0qGonVjaywoF18Tcz8yls7482cY6b69m6f9 7BwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=IIWs+Ui4HfUQQ26p5GiVrlnnmnvOE0UJfrfS79pzeoo=; b=JJH8LCo9ZSFGesAet2nmbRV+IQxJ7AfT91llGflM4CNrCO+lpsTSHcXakLvcPaSz9U Z5Agfb6pYjcOegQNb4ptgoN1Uui5s61Rw6exZfq9XYkPWn1R2pb6V2SjqTDMzpXW6s2w kBvJkOueHbYgGoyCwfsmqR+RrwvBNMmrA29LP+Rg9MYD9aNQkuM1WKT6rdWJldpd9Knw AgS623OYTzmkjMZ82CWxiAr8MjCDSj0HOjAOS3PY9jsomnEpaTLyP+Qg5n5FwSAUOjIb XnfnzpohOdbIHkhDV2a0vheURlQhDN4yMdG97eEy4SEHbK3tkL522FFIZpLr+H92C70F nbQw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gb15-20020a170907960f00b007219be3906bsi6231512ejc.578.2022.07.22.03.15.55; Fri, 22 Jul 2022 03:16:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234930AbiGVJ7M (ORCPT + 99 others); Fri, 22 Jul 2022 05:59:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234516AbiGVJ7D (ORCPT ); Fri, 22 Jul 2022 05:59:03 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C06FF3FA13 for ; Fri, 22 Jul 2022 02:59:02 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id 8F04568AFE; Fri, 22 Jul 2022 11:58:59 +0200 (CEST) Date: Fri, 22 Jul 2022 11:58:59 +0200 From: Christoph Hellwig To: Tvrtko Ursulin Cc: Robert Beckett , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , Daniel Vetter , kernel@collabora.com, Christoph Hellwig , Thomas Hellstrom , Matthew Auld , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] drm/i915: stop using swiotlb Message-ID: <20220722095859.GB14113@lst.de> References: <20220721174307.1085741-1-bob.beckett@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 22, 2022 at 10:45:54AM +0100, Tvrtko Ursulin wrote: >> - unsigned int size = swiotlb_max_segment(); >> - >> - if (size == 0) >> - size = UINT_MAX; > > On a more detailed look, there was a CI failure which makes me think this > cap might need to stay. Because max sg segment is unsigned int. So I wonder > if sg contstruction overflows without it. > > If this quick analysis is right, you could leave i915_sg_segment_size > helper and cap the return from dma_max_mapping_size to UINT_MAX in it. As dma_max_mapping_size retuns a size_t it would be good to make all variables using it a size_t as well. In places where that gets lower to an unsigned int your probably want this cap.