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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DEE51C48BC2 for ; Fri, 25 Jun 2021 15:50:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C32F461952 for ; Fri, 25 Jun 2021 15:50:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230008AbhFYPxI (ORCPT ); Fri, 25 Jun 2021 11:53:08 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:57120 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229774AbhFYPxH (ORCPT ); Fri, 25 Jun 2021 11:53:07 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 15PFo8Qb017261; Fri, 25 Jun 2021 17:50:08 +0200 Date: Fri, 25 Jun 2021 17:50:08 +0200 From: Willy Tarreau To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: Geert Uytterhoeven , Michael Turquette , Stephen Boyd , Rob Herring , Greg Kroah-Hartman , Andrew Lunn , Gregory Clement , Sebastian Hesselbarth , Vladimir Vid , Marek =?iso-8859-1?Q?Beh=FAn?= , linux-clk , "open list:SERIAL DRIVERS" , Linux Kernel Mailing List , Linux ARM Subject: Re: [PATCH v2 07/11] math64: New DIV_U64_ROUND_CLOSEST helper Message-ID: <20210625155008.GB16901@1wt.eu> References: <20210624224909.6350-1-pali@kernel.org> <20210625143617.12826-1-pali@kernel.org> <20210625143617.12826-8-pali@kernel.org> <20210625153803.u6uesckcqyvvo7dl@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210625153803.u6uesckcqyvvo7dl@pali> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 25, 2021 at 05:38:03PM +0200, Pali Rohár wrote: > On Friday 25 June 2021 17:22:31 Geert Uytterhoeven wrote: > > > +/* > > > + * DIV_U64_ROUND_CLOSEST - unsigned 64bit divide with 32bit divisor rounded to nearest integer > > > + * @dividend: unsigned 64bit dividend > > > + * @divisor: unsigned 32bit divisor > > > + * > > > + * Divide unsigned 64bit dividend by unsigned 32bit divisor > > > + * and round to closest integer. > > > + * > > > + * Return: dividend / divisor rounded to nearest integer > > > + */ > > > +#define DIV_U64_ROUND_CLOSEST(dividend, divisor) \ > > > + ({ u32 _tmp = (divisor); div_u64((u64)(dividend) + _tmp / 2, _tmp); }) > > > > Given "dividend" should already be an unsigned 64-bit value, I don't > > think the cast to "u64" is needed. Similar macros in this file also > > don't have the cast. > > It is just to ensure that plus operation between dividend and _tmp is > evaluated in 64-bit context to prevent overflow. Just a case when user > calls this macro with 32-bit dividend param. As it is a macro (and not > inline function) type is not automatically enforced. I agree, a large u32 argument added to _tmp/2 could overflow and remain 32 bits, yielding an incorrect result. The cast is mandatory here (and will either emit no code, or be useful). The only trap I'm seeing is if a negative signed int is passed in dividend, it will be sign-extended and will give a large u64 value. A preliminary u32 cast could avoid this but would break valid u64 arguments, and I'd claim we never know what the user wants if this happens in the first place. Willy 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 X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 30311C2B9F4 for ; Fri, 25 Jun 2021 15:52:10 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 018EB61952 for ; Fri, 25 Jun 2021 15:52:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 018EB61952 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=1wt.eu Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=J5cmLrmpNq8AXWszQE9crLdgGBdhdMJAheuSBHwSI80=; b=id5W+hHWYE+m2f aNDUaJ0FMC0nb+3R03AQnlqkbtYbsrRsS7HndRgGxgkcJ2T9Hdbn5k1wfxB8L9TDvMIN8clsswzVj 6iWayzYl6hO7NOhWbp5hbsNy1n6xgLo5HJxTVlvVSaTzR/v5ffOt0iqkgla4GUnsrKeeGWxu1kUqh +UKQ5g9Dgxkxcej3VUZIRq4zfgP7+ysl700cHVpqWOd1z/y70AokEY5rrn9kZCcnMCpoGz1DM1v5Y Rx0LZO1ll+nb2331ySJU5dzoqlDr35spCe3ewejA3tIL2qOIong3JcfdioNpvuxClXhQJoeS3km3H l2Pam6lEMnDzL6Djh3yw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwo6O-002D2U-3f; Fri, 25 Jun 2021 15:50:44 +0000 Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwo6J-002D0r-Ed for linux-arm-kernel@lists.infradead.org; Fri, 25 Jun 2021 15:50:41 +0000 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 15PFo8Qb017261; Fri, 25 Jun 2021 17:50:08 +0200 Date: Fri, 25 Jun 2021 17:50:08 +0200 From: Willy Tarreau To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: Geert Uytterhoeven , Michael Turquette , Stephen Boyd , Rob Herring , Greg Kroah-Hartman , Andrew Lunn , Gregory Clement , Sebastian Hesselbarth , Vladimir Vid , Marek =?iso-8859-1?Q?Beh=FAn?= , linux-clk , "open list:SERIAL DRIVERS" , Linux Kernel Mailing List , Linux ARM Subject: Re: [PATCH v2 07/11] math64: New DIV_U64_ROUND_CLOSEST helper Message-ID: <20210625155008.GB16901@1wt.eu> References: <20210624224909.6350-1-pali@kernel.org> <20210625143617.12826-1-pali@kernel.org> <20210625143617.12826-8-pali@kernel.org> <20210625153803.u6uesckcqyvvo7dl@pali> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210625153803.u6uesckcqyvvo7dl@pali> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210625_085039_884768_39A100D3 X-CRM114-Status: GOOD ( 16.09 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jun 25, 2021 at 05:38:03PM +0200, Pali Roh=E1r wrote: > On Friday 25 June 2021 17:22:31 Geert Uytterhoeven wrote: > > > +/* > > > + * DIV_U64_ROUND_CLOSEST - unsigned 64bit divide with 32bit divisor = rounded to nearest integer > > > + * @dividend: unsigned 64bit dividend > > > + * @divisor: unsigned 32bit divisor > > > + * > > > + * Divide unsigned 64bit dividend by unsigned 32bit divisor > > > + * and round to closest integer. > > > + * > > > + * Return: dividend / divisor rounded to nearest integer > > > + */ > > > +#define DIV_U64_ROUND_CLOSEST(dividend, divisor) \ > > > + ({ u32 _tmp =3D (divisor); div_u64((u64)(dividend) + _tmp / 2= , _tmp); }) > > = > > Given "dividend" should already be an unsigned 64-bit value, I don't > > think the cast to "u64" is needed. Similar macros in this file also > > don't have the cast. > = > It is just to ensure that plus operation between dividend and _tmp is > evaluated in 64-bit context to prevent overflow. Just a case when user > calls this macro with 32-bit dividend param. As it is a macro (and not > inline function) type is not automatically enforced. I agree, a large u32 argument added to _tmp/2 could overflow and remain 32 bits, yielding an incorrect result. The cast is mandatory here (and will either emit no code, or be useful). The only trap I'm seeing is if a negative signed int is passed in dividend, it will be sign-extended and will give a large u64 value. A preliminary u32 cast could avoid this but would break valid u64 arguments, and I'd claim we never know what the user wants if this happens in the first place. Willy _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel