Received: by 10.223.176.5 with SMTP id f5csp2115774wra; Thu, 8 Feb 2018 08:41:04 -0800 (PST) X-Google-Smtp-Source: AH8x224Lig+1WhcYFinZti5zx4Di8/PeFtqMQcBlrpuzmfqjQtQPyg7xiW2UQn9XpfWc7OL6yADL X-Received: by 10.98.7.214 with SMTP id 83mr1272264pfh.130.1518108064585; Thu, 08 Feb 2018 08:41:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518108064; cv=none; d=google.com; s=arc-20160816; b=vhrC6USZCNKo4YVSjWs6aZ6aWM800GlQK/V3SyhZH87YkCqeURotXWB/mIBGBA6Rvj v09yjlrhKAn6LsBTFj9vgNNLpYeotFG5eaYJ7RShBZB+csN99lxwxTC2Dm937NMUacil B9WzLVySgffHRPUfDAEC+AgXNevG1hhsYMZlUhyyKofqVl7ZbIUx2NfgbYMnz7SxvrNB 6F2R6bS+ZPxj36TmYoOqzckVdrW4sR6zYagkwHP7dlM26/CY/A8HEYFP9O/ph1EU98L5 6NDqzbVhXZMMArXkKp6XxM+7t8DlSnOJDTYE2aF8iwcBwdFkUIajbshfQBMKczMjmdqT 9FZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=DsejmAqXDuy2x2g75VaPRR3GMiU3YxBmo11BVto+pE4=; b=JPBMl+VYMUA2t/vfnSw934F2DgxdrFyvqdI6OUnRsKf540Im03F4LKOOdyh7lnyNiC OPHZl8LO1GwjpwOY3nOJy9/SlvbCenCAZNC2XvdAq6t53Uyx9NslMXZYWGlh4C/GVjSD 7cykUhOH+CTyW3oNjBQqZz/aNKwf9oDu74cI+Pl9Ej8u+8AFUgSp3eie5USsoCiQ4kDX TJaEFxdzaeSRZPImXECszkZ5FCz7OGQUXYBNhzBPJa57GP5TLHTjwSi6K91fUL+IglzM 76Vtz7C3bXabPQliKf79f8O/rJz7cgkoORjVxqHxTdHqwFvTZSLMIP1cEj9JI17tS0fF CRrA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j11si151461pgs.614.2018.02.08.08.40.49; Thu, 08 Feb 2018 08:41:04 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752497AbeBHQjy (ORCPT + 99 others); Thu, 8 Feb 2018 11:39:54 -0500 Received: from gateway32.websitewelcome.com ([192.185.145.171]:23414 "EHLO gateway32.websitewelcome.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752433AbeBHQjq (ORCPT ); Thu, 8 Feb 2018 11:39:46 -0500 Received: from cm10.websitewelcome.com (cm10.websitewelcome.com [100.42.49.4]) by gateway32.websitewelcome.com (Postfix) with ESMTP id C2E43281BC for ; Thu, 8 Feb 2018 10:39:45 -0600 (CST) Received: from gator4166.hostgator.com ([108.167.133.22]) by cmsmtp with SMTP id jpEfeO4W0cGlpjpEfeNyph; Thu, 08 Feb 2018 10:39:45 -0600 Received: from [189.175.4.238] (port=50978 helo=[192.168.1.69]) by gator4166.hostgator.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1ejpEf-002iSA-Ar; Thu, 08 Feb 2018 10:39:45 -0600 Subject: Re: [PATCH v3 4/8] i2c: ov9650: use 64-bit arithmetic instead of 32-bit To: Sakari Ailus , "Gustavo A. R. Silva" Cc: Mauro Carvalho Chehab , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org References: <6f6fd607cf3428d6ab115f1deaa82c4963b170f1.1517929336.git.gustavo@embeddedor.com> <20180207215944.quwowjy52dclk7uc@valkosipuli.retiisi.org.uk> From: "Gustavo A. R. Silva" Message-ID: <3518830f-180c-2bf0-1319-eb4af8cc556f@embeddedor.com> Date: Thu, 8 Feb 2018 10:39:39 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180207215944.quwowjy52dclk7uc@valkosipuli.retiisi.org.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4166.hostgator.com X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - embeddedor.com X-BWhitelist: no X-Source-IP: 189.175.4.238 X-Source-L: No X-Exim-ID: 1ejpEf-002iSA-Ar X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.69]) [189.175.4.238]:50978 X-Source-Auth: garsilva@embeddedor.com X-Email-Count: 4 X-Source-Cap: Z3V6aWRpbmU7Z3V6aWRpbmU7Z2F0b3I0MTY2Lmhvc3RnYXRvci5jb20= X-Local-Domain: yes Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sakari, On 02/07/2018 03:59 PM, Sakari Ailus wrote: > Hi Gustavo, > > On Tue, Feb 06, 2018 at 10:47:50AM -0600, Gustavo A. R. Silva wrote: >> Add suffix ULL to constants 10000 and 1000000 in order to give the >> compiler complete information about the proper arithmetic to use. >> Notice that these constants are used in contexts that expect >> expressions of type u64 (64 bits, unsigned). >> >> The following expressions: >> >> (u64)(fi->interval.numerator * 10000) >> (u64)(iv->interval.numerator * 10000) >> fiv->interval.numerator * 1000000 / fiv->interval.denominator >> >> are currently being evaluated using 32-bit arithmetic. >> >> Notice that those casts to u64 for the first two expressions are only >> effective after such expressions are evaluated using 32-bit arithmetic, >> which leads to potential integer overflows. So based on those casts, it >> seems that the original intention of the code is to actually use 64-bit >> arithmetic instead of 32-bit. >> >> Also, notice that once the suffix ULL is added to the constants, the >> outer casts to u64 are no longer needed. >> >> Addresses-Coverity-ID: 1324146 ("Unintentional integer overflow") >> Fixes: 84a15ded76ec ("[media] V4L: Add driver for OV9650/52 image sensors") >> Fixes: 79211c8ed19c ("remove abs64()") >> Signed-off-by: Gustavo A. R. Silva >> --- >> Changes in v2: >> - Update subject and changelog to better reflect the proposed code changes. >> - Add suffix ULL to constants instead of casting variables. >> - Remove unnecessary casts to u64 as part of the code change. >> - Extend the same code change to other similar expressions. >> >> Changes in v3: >> - None. >> >> drivers/media/i2c/ov9650.c | 9 +++++---- >> 1 file changed, 5 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c >> index e519f27..e716e98 100644 >> --- a/drivers/media/i2c/ov9650.c >> +++ b/drivers/media/i2c/ov9650.c >> @@ -1130,7 +1130,7 @@ static int __ov965x_set_frame_interval(struct ov965x *ov965x, >> if (fi->interval.denominator == 0) >> return -EINVAL; >> >> - req_int = (u64)(fi->interval.numerator * 10000) / >> + req_int = fi->interval.numerator * 10000ULL / >> fi->interval.denominator; > > This has been addressed by your earlier patch "i2c: ov9650: fix potential integer overflow in > __ov965x_set_frame_interval" I tweaked a little. It's not in media tree > master yet. > Yeah. Actually this patch is supposed to be an improved version of the one you mention. That is why this is version 3. Also, I wonder if the same issue you mention below regarding 32-bit ARM applies in this case too? >> >> for (i = 0; i < ARRAY_SIZE(ov965x_intervals); i++) { >> @@ -1139,7 +1139,7 @@ static int __ov965x_set_frame_interval(struct ov965x *ov965x, >> if (mbus_fmt->width != iv->size.width || >> mbus_fmt->height != iv->size.height) >> continue; >> - err = abs((u64)(iv->interval.numerator * 10000) / >> + err = abs(iv->interval.numerator * 10000ULL / > > This and the chunk below won't work on e.g. 32-bit ARM. do_div(), please. > Thanks for pointing this out. >> iv->interval.denominator - req_int); >> if (err < min_err) { >> fiv = iv; >> @@ -1148,8 +1148,9 @@ static int __ov965x_set_frame_interval(struct ov965x *ov965x, >> } >> ov965x->fiv = fiv; >> >> - v4l2_dbg(1, debug, &ov965x->sd, "Changed frame interval to %u us\n", >> - fiv->interval.numerator * 1000000 / fiv->interval.denominator); >> + v4l2_dbg(1, debug, &ov965x->sd, "Changed frame interval to %llu us\n", >> + fiv->interval.numerator * 1000000ULL / >> + fiv->interval.denominator); I wonder if do_div should be used for the code above? I appreciate your feedback. Thank you! -- Gustavo