Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932646AbbKCUoz (ORCPT ); Tue, 3 Nov 2015 15:44:55 -0500 Received: from mail-io0-f180.google.com ([209.85.223.180]:33411 "EHLO mail-io0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755334AbbKCUow (ORCPT ); Tue, 3 Nov 2015 15:44:52 -0500 MIME-Version: 1.0 In-Reply-To: References: <20151027.233235.1641084823622810663.davem@davemloft.net> <5637C8DF.800@kernel.org> <1446512176.17404.30.camel@kernel.crashing.org> <1446555200.1870849.427743457.63139285@webmail.messagingengine.com> Date: Tue, 3 Nov 2015 12:44:51 -0800 X-Google-Sender-Auth: FQNuTZxnJ4PpBykkhig09eagdSc Message-ID: Subject: Re: [GIT] Networking From: Linus Torvalds To: Hannes Frederic Sowa Cc: Andy Lutomirski , Benjamin Herrenschmidt , Andy Lutomirski , David Miller , Andrew Morton , Network Development , Linux Kernel Mailing List , Sasha Levin Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2463 Lines: 65 On Tue, Nov 3, 2015 at 12:05 PM, Linus Torvalds wrote: > result = add_overflow( > mul_overflow(sec, SEC_CONVERSION, &overflow), > mul_overflow(nsec, NSEC_CONVERSION, &overflow), > &overflow); > > return overflow ? MAX_JIFFIES : result; Thinking more about this example, I think the gcc interface for multiplication overflow is fine. It would end up something like if (mul_overflow(sec, SEC_CONVERSION, &sec)) return MAX_JIFFY_OFFSET; if (mul_overflow(nsec, NSEC_CONVERSION, &nsec)) return MAX_JIFFY_OFFSET; sum = sec + nsec; if (sum < sec || sum > MAX_JIFFY_OFFSET) return MAX_JIFFY_OFFSET; return sum; and that doesn't look horribly ugly to me. That said, I do wonder how many of our interfaces really want overflow, and how many just want saturation (or even clamping to a maximum value). For example, one of the *common* cases of multiplication overflow we have had is for memory allocation where we do things like buffer = kmalloc(sizeof(something) * nr, GFP_KERNEL); and we've fixed them by moving them to 'kcalloc()'. But as with the jiffies conversion above, it would actually be sufficient to just saturate to a maximum value instead, and depending on that causing the allocation to fail. So it may actually be that most users really don't even *want* "overflow". Does anybody have any particular other "uhhuh, overflow in multiplication" issues in mind? Because the interface for a saturating multiplication (or addition, for that matter) would actually be much easier. And would be trivial to have as an inline asm for compatibility with older versions of gcc too. Then you could just do that jiffies conversion - or allocation, for that matter - without any special overflow handling at all. Doing buf = kmalloc(sat_mul(sizeof(x), nr), GFP_KERNEL); would just magically work. And the above jiffies conversion would still want to clamp things to MAX_JIFFY_OFFSET (because we consider "jiffies" to be an offset from now, and while it's "unsigned long", we clamp the offset to half the range), but it would still be a rather natural model for it too. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/