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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 71ED0CCA47F for ; Fri, 22 Jul 2022 10:14:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234543AbiGVKOK (ORCPT ); Fri, 22 Jul 2022 06:14:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49254 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231226AbiGVKOH (ORCPT ); Fri, 22 Jul 2022 06:14:07 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EA4247694F for ; Fri, 22 Jul 2022 03:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658484846; x=1690020846; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=SKPrtA2rILFUjYQxZJSiARCkKS6SUAGjnJyVAykGQWc=; b=ZRiHLLidczJPd5qhZH4OwhW/C5ED3xhr1iwB3odVXMNd9Tig6RCeQAPz TCmgOmv6hmCo+a9BxL+EMR8YQgnVKM5PnkP4orAcqXDRtQfn9XULrHz/+ /ty7YgJu4hxhN0VJ1CaLGOAhKYLu6tqK7Nv8ll7wOBYC94iX72W9qwMNs UINVyEX2M2iy4mCHiMpXkZzZSFysq6/rbyxh8LAfV8AMmEgZhb7CBEvFU C9zjsUz8mMXlCbalsFkURCCT0LKZHseb8FxmnI581VMhO9+Nm8BxKIqDN UkdHT2Aa6003QGJRSK/un4jWH3EtRzmT7vUElhF5bCi8sonlCouCrXv2A A==; X-IronPort-AV: E=McAfee;i="6400,9594,10415"; a="313006451" X-IronPort-AV: E=Sophos;i="5.93,185,1654585200"; d="scan'208";a="313006451" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jul 2022 03:14:06 -0700 X-IronPort-AV: E=Sophos;i="5.93,185,1654585200"; d="scan'208";a="574119258" Received: from lflintof-mobl1.ger.corp.intel.com (HELO [10.213.217.10]) ([10.213.217.10]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jul 2022 03:14:03 -0700 Message-ID: Date: Fri, 22 Jul 2022 11:13:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] drm/i915: stop using swiotlb Content-Language: en-US To: Christoph Hellwig Cc: Robert Beckett , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , Daniel Vetter , kernel@collabora.com, Thomas Hellstrom , Matthew Auld , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20220721174307.1085741-1-bob.beckett@collabora.com> <20220722095859.GB14113@lst.de> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc In-Reply-To: <20220722095859.GB14113@lst.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22/07/2022 10:58, Christoph Hellwig wrote: > 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. Yep. Problem we have is struct scatterlist length field, which is unsigned int, since all our backing storage handling is built on top of it. Therefore I think capping in this helper should be good. Regards, Tvrtko