From nobody Sat Apr 11 11:11:36 2026 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 AD383C00140 for ; Sat, 13 Aug 2022 01:10:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237732AbiHMBKG (ORCPT ); Fri, 12 Aug 2022 21:10:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56838 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238560AbiHMBJn (ORCPT ); Fri, 12 Aug 2022 21:09:43 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A0922ABD4A for ; Fri, 12 Aug 2022 18:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1660352961; x=1691888961; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=feUjbyPzk1hzgECdJlMvMWye5xjHwhOw5XjgA5LI53c=; b=AizS0sVXJKhBxP2p9g2W96YQVgX882sz0e7YBvGy30VhFVRsrR6AxbCU k4iwGvAIeo3fpYSNlKeM/ulj8jpqWjkKkt/XaHgEXkkpXxip4tokz2NvQ JH9IIjniUYqjDlpbOy2MKfGjM0l/ssUoukJzURRP9kNs6IlJuFxoKVOju SV5ItV8PH32gAVgNKHbqIwSYBt4yveQW8Kt7WpS78lc7EnNgMyJTZXMDZ 3pePnDbc79QBm1StoOkOPZDImdkyo882Q7B86SGPRyyfpmYAUWCPkWves uWIy7o4UdMLOqvxWIjhJb77pw+YF/p2dy3xjl6BHjsWu3yDbPxNS/U9PA g==; X-IronPort-AV: E=McAfee;i="6400,9594,10437"; a="271488748" X-IronPort-AV: E=Sophos;i="5.93,233,1654585200"; d="scan'208";a="271488748" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Aug 2022 18:09:21 -0700 X-IronPort-AV: E=Sophos;i="5.93,233,1654585200"; d="scan'208";a="666038402" Received: from akoska-mobl1.ger.corp.intel.com (HELO hades.ger.corp.intel.com) ([10.252.36.156]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Aug 2022 18:09:18 -0700 From: Gwan-gyeong Mun To: intel-gfx@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, mchehab@kernel.org, chris@chris-wilson.co.uk, matthew.auld@intel.com, thomas.hellstrom@linux.intel.com, jani.nikula@intel.com, nirmoy.das@intel.com, airlied@linux.ie, daniel@ffwll.ch, andi.shyti@linux.intel.com, andrzej.hajda@intel.com Subject: [PATCH v6 8/8] drm/i915: Remove truncation warning for large objects Date: Sat, 13 Aug 2022 04:08:57 +0300 Message-Id: <20220813010857.4043956-9-gwan-gyeong.mun@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220813010857.4043956-1-gwan-gyeong.mun@intel.com> References: <20220813010857.4043956-1-gwan-gyeong.mun@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Chris Wilson Having addressed the issues surrounding incorrect types for local variables and potential integer truncation in using the scatterlist API, we have closed all the loop holes we had previously identified with dangerously large object creation. As such, we can eliminate the warning put in place to remind us to complete the review. Signed-off-by: Chris Wilson Signed-off-by: Gwan-gyeong Mun Cc: Tvrtko Ursulin Cc: Brian Welty Cc: Matthew Auld Cc: Thomas Hellstr=C3=B6m Testcase: igt@gem_create@create-massive Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4991 Reviewed-by: Nirmoy Das Reviewed-by: Mauro Carvalho Chehab Reviewed-by: Andrzej Hajda --- drivers/gpu/drm/i915/gem/i915_gem_object.h | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h b/drivers/gpu/drm/i= 915/gem/i915_gem_object.h index 0cf31adbfd41..dd2762da332f 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h @@ -20,25 +20,10 @@ =20 enum intel_region_id; =20 -/* - * XXX: There is a prevalence of the assumption that we fit the - * object's page count inside a 32bit _signed_ variable. Let's document - * this and catch if we ever need to fix it. In the meantime, if you do - * spot such a local variable, please consider fixing! - * - * We can check for invalidly typed locals with typecheck(), see for examp= le - * i915_gem_object_get_sg(). - */ -#define GEM_CHECK_SIZE_OVERFLOW(sz) \ - GEM_WARN_ON((sz) >> PAGE_SHIFT > INT_MAX) - static inline bool i915_gem_object_size_2big(u64 size) { struct drm_i915_gem_object *obj; =20 - if (GEM_CHECK_SIZE_OVERFLOW(size)) - return true; - if (overflows_type(size, obj->base.size)) return true; =20 --=20 2.34.1