Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1287068ybt; Thu, 18 Jun 2020 05:16:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzyzyccT1SbsEPaIKs3KlkTbv/iJB25Xt4UZT0MwkCixIWud5rCtr8G9SD6+GjoUD4XdktO X-Received: by 2002:a50:c219:: with SMTP id n25mr3817266edf.306.1592482608971; Thu, 18 Jun 2020 05:16:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592482608; cv=none; d=google.com; s=arc-20160816; b=j/I+AbyHm7kpt6gv7FgEGM+2ph6SWg2U6fstHIKu+tJjpqHpjNmG7e/lSem6L937RW kZnHb+CNq51Qbl53DujNbjVx3W0u0uEmJMZcEHnkMTQTQVLSTKPsK2t9MMWIe8JzuDUF cYmJZrO0f7iqBAmxfkYw2MdxxZW1bF2hL0IP44iBOvjgxGmaEliA5yaQ2khnWN9f/RE5 N5roeZ3NbXur3GeCtySoLtlvmLHndigyWXJmQrj0EZI+rvByIh8jOXneg4RNHjOMBozE W70oYIIAY3iRnF2N0OMSHtFebbzsKmcD1zLqJMmpEWGV5m59HqdMgGky8+Ud5x7W6Dix pBgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=pB3vemKMUXIiIG4u3aYppbj23dv61iNLvcw2ZI+MavU=; b=eU44nmZjG5D5C9Hz+/FutUIZ0GIc+Z8izSTtOYrkJwYtIPcITuRoL2c2Gd2OLbc6i0 oirk1wSlPXMWHMJvWofAWRAuzGhleLb6UXd/jr7KdRgezTL0DEZSZJ298wkrt6kLDg3L JerNOqiNocEoLX8avXdZsc4kaRRlJt1XXpfpXJZDlPV8WKt4eL4artLFC81QITZwqz01 G2za8ZxGXG0LJKOxj2XcY8/3N7d5lo5WeZZ4EEq3kfyIUTVY/PQNuT/rd8tckkvOQ2Z3 OxrC2sMCtsxeZqaM/LtX4EiK71rTC/oxHyWbmgvziplBPSb5iP6Lmmu8AOONq+Ea74YK RZkA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t9si1661033eju.485.2020.06.18.05.16.26; Thu, 18 Jun 2020 05:16:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729481AbgFRMOP (ORCPT + 99 others); Thu, 18 Jun 2020 08:14:15 -0400 Received: from foss.arm.com ([217.140.110.172]:48996 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727845AbgFRMOK (ORCPT ); Thu, 18 Jun 2020 08:14:10 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 516561045; Thu, 18 Jun 2020 05:14:07 -0700 (PDT) Received: from e110455-lin.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 30A003F71F; Thu, 18 Jun 2020 05:14:07 -0700 (PDT) Received: by e110455-lin.cambridge.arm.com (Postfix, from userid 1000) id E2260682412; Thu, 18 Jun 2020 13:14:05 +0100 (BST) Date: Thu, 18 Jun 2020 13:14:05 +0100 From: Liviu Dudau To: Colin King Cc: Brian Starkey , David Airlie , Daniel Vetter , dri-devel@lists.freedesktop.org, kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] drm/arm: fix unintentional integer overflow on left shift Message-ID: <20200618121405.GJ159988@e110455-lin.cambridge.arm.com> References: <20200618100400.11464-1-colin.king@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200618100400.11464-1-colin.king@canonical.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 18, 2020 at 11:04:00AM +0100, Colin King wrote: > From: Colin Ian King Hi Colin, > > Shifting the integer value 1 is evaluated using 32-bit arithmetic > and then used in an expression that expects a long value leads to > a potential integer overflow. I'm afraid this explanation makes no sense to me. Do you care to explain better what you think the issue is? If the shift is done as 32-bit arithmetic and then promoted to long how does the overflow happen? Best regards, Liviu > Fix this by using the BIT macro to > perform the shift to avoid the overflow. > > Addresses-Coverity: ("Unintentional integer overflow") > Fixes: ad49f8602fe8 ("drm/arm: Add support for Mali Display Processors") > Signed-off-by: Colin Ian King > --- > drivers/gpu/drm/arm/malidp_planes.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/arm/malidp_planes.c b/drivers/gpu/drm/arm/malidp_planes.c > index 37715cc6064e..ab45ac445045 100644 > --- a/drivers/gpu/drm/arm/malidp_planes.c > +++ b/drivers/gpu/drm/arm/malidp_planes.c > @@ -928,7 +928,7 @@ int malidp_de_planes_init(struct drm_device *drm) > const struct malidp_hw_regmap *map = &malidp->dev->hw->map; > struct malidp_plane *plane = NULL; > enum drm_plane_type plane_type; > - unsigned long crtcs = 1 << drm->mode_config.num_crtc; > + unsigned long crtcs = BIT(drm->mode_config.num_crtc); > unsigned long flags = DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_90 | DRM_MODE_ROTATE_180 | > DRM_MODE_ROTATE_270 | DRM_MODE_REFLECT_X | DRM_MODE_REFLECT_Y; > unsigned int blend_caps = BIT(DRM_MODE_BLEND_PIXEL_NONE) | > -- > 2.27.0.rc0 > -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯