From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753549AbcIDJEO (ORCPT ); Sun, 4 Sep 2016 05:04:14 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:56732 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752933AbcIDJEM (ORCPT ); Sun, 4 Sep 2016 05:04:12 -0400 Date: Sun, 4 Sep 2016 11:01:51 +0200 (CEST) From: Thomas Gleixner To: Liav Rehana cc: "linux-kernel@vger.kernel.org" , "john.stultz@linaro.org" , Noam Camus , Elad Kanfi Subject: RE: [PATCH] Fix chance of sign extension to nsec after its msb is set during calculation. In-Reply-To: Message-ID: References: <1472728478-3788-1-git-send-email-liavr@mellanox.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 4 Sep 2016, Liav Rehana wrote: Please do not top post and trim your reply. > The root of the problem is that in case the multiplication of delta and > tkr->mult in the line that I've changed is too big that the MSB of the > result is set, then the shift will cause an unwanted sign extension. I completely understand that, but as I said before: > > This typecast is just a baindaid. What happens if you double the > > suspend time? The multiplication will simply overflow. So the proper > > fix is to sanity check delta and do multiple conversions if delta is > > big enough. Preferrably this happens somewhere at the call site and > > not in this hotpath function. > That sign extension will be avoided completely if the variable nsec was > unsigned (u64 instead of s64), so I think the correct solution for this > is to change the type of nsec to u64. That's a different story and its not a solution for the general problem of delta * mult >= (1 << 31) or delta * mult >= (1 << 32) Thanks, tglx