Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp1348269pxv; Fri, 25 Jun 2021 10:45:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwq4vkqDUyTLOQjyF0ao+KbnPWWTaEBeXihgqJUj4jxq6r6gvS5Uizvz/ERL7che4nZcuth X-Received: by 2002:a92:1e08:: with SMTP id e8mr8543913ile.10.1624643136545; Fri, 25 Jun 2021 10:45:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624643136; cv=none; d=google.com; s=arc-20160816; b=soPQYUYwq8ZnuvXITAeKG4S/5N9rzj+TB6Z6aaRFXL8RtnKRyo/lUhf95s5CkpYOqC KifyBA58NtQpiNmrXSKqFhtMCgmdxG5je0V8opHn5hYHi6xbOmC90g4MOY+eB8pDpfcC hvF/hDw/K+YNJBPA5sPL8UZNE4sSdwHaNHMDzGNKmWIw9rvuxi0AW2kJ+Vl4S+yenXjB 3UdmBrI39z+tvJOW3MZ1aalhZfomp8eSJlahxnOwyhzzGjjiXiAyjP1j6in/zeyRr3MO 4Hij0f3y3yiyCYPFNMyL2aErvSVnQu9qILorGf0LOktHwmNA0CQ1HPjbOprEwrx48FHh 4fEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=2MrLUSajE/v2rfi+S26uNe0GlBF7odlAIJwMiGR4tdY=; b=x3Vzea/+I2raz+YPQ++hquCPVGt4XEPQEOAV4yOgjIcb+vnZpFfbjdKE/AJOTdqY3r sKkTjlilzxvCnLeaINstMUHnPat7OGgVeKJcwPj2cgFKAltDyz8fF0sWv5s0iaO1+ASn 0/PgDwZ2KXdXQVphC+4pXrtV8NJUY2/m5W3e6xTwOOtwukccsjvsLXq9xsklHVpiRf/h znsUJI7sg0d7cwSA/bq5Xr1zdOEfOEG+wtzL1acKo3XjjbxZiD++3l+VJgwPqz4ORYXi THRvXi5sU5MkWvbo2cXnJHhn/c7FQrjoT8z+HtxOYSkb3yLyEn01FONaLOYOrjU2SCyq X0Ug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=nYYpRXzL; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d1si6345334ila.19.2021.06.25.10.45.23; Fri, 25 Jun 2021 10:45:36 -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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=nYYpRXzL; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229671AbhFYRrM (ORCPT + 99 others); Fri, 25 Jun 2021 13:47:12 -0400 Received: from mail.kernel.org ([198.145.29.99]:58864 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229531AbhFYRrM (ORCPT ); Fri, 25 Jun 2021 13:47:12 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 0A0BC6157E; Fri, 25 Jun 2021 17:44:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1624643091; bh=OtC2yHps4Gx+4TrmMrLMl5zOxwe81NfKarp7uzkjwAE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nYYpRXzLYtG50IJPZ9h6GR6iiH9qLv/987IdlIdK5dKrh21BIZ+L9nZMW5wmsXkCj bkUCxO6poe0/XjIdqzeMhQUJ02SikvRfoluA2b6j3zcVhcWy8WQkESoMv1CEmoTmRf zvSm7MgsEl7hsV4kfl2c2VGwTLvBWFcABJdyNLzV5PmWWc5O80dWaq8zbdkSs05jhx GpL/nHSdwHT5MVeB5wCK9WIUjmSBtYNzh3geb6VS8EMzDIVIWVzQNv8kPueBPLv9q2 9SCT6wbXxcTWntCFYGb3TwaibrE+PetCqMeofXd+cAlAs+iRV4eyCSarQKU8lYJfyq Jz4kJvGKRbPiA== Received: by pali.im (Postfix) id 97367A7D; Fri, 25 Jun 2021 19:44:48 +0200 (CEST) Date: Fri, 25 Jun 2021 19:44:48 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Geert Uytterhoeven Cc: Willy Tarreau , Michael Turquette , Stephen Boyd , Rob Herring , Greg Kroah-Hartman , Andrew Lunn , Gregory Clement , Sebastian Hesselbarth , Vladimir Vid , Marek =?utf-8?B?QmVow7pu?= , 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: <20210625174448.kje4pvg5ixpu3vaw@pali> References: <20210624224909.6350-1-pali@kernel.org> <20210625143617.12826-1-pali@kernel.org> <20210625143617.12826-8-pali@kernel.org> <20210625153803.u6uesckcqyvvo7dl@pali> <20210625155008.GB16901@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 25 June 2021 19:39:10 Geert Uytterhoeven wrote: > Hi Willy, > > On Fri, Jun 25, 2021 at 5:50 PM Willy Tarreau wrote: > > 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). > > Fair enough. > So we want to add a cast to DIV64_U64_ROUND_CLOSEST() above, too? For DIV64_U64_ROUND_CLOSEST() it is not needed. divisor is copied into u64 _tmp variable and therefore "(dividend) + _tmp / 2" is already evaluated in 64-bit context even when dividend is only 32-bit. The only trap is that negative value as written below. > > 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. > > Yep. > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds