From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [GIT] Networking Date: Mon, 2 Nov 2015 17:58:29 -0800 Message-ID: References: <20151027.233235.1641084823622810663.davem@davemloft.net> <5637C8DF.800@kernel.org> <1446512176.17404.30.camel@kernel.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Benjamin Herrenschmidt , Andy Lutomirski , David Miller , Hannes Frederic Sowa , Andrew Morton , Network Development , Linux Kernel Mailing List , Sasha Levin To: Linus Torvalds Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Mon, Nov 2, 2015 at 5:54 PM, Linus Torvalds wrote: > > The biggest problem - and where the compiler could actually help us - > tends to be multiplication overflows. We have several (not *many*, but > certainly more than just a couple) cases where we simply check by > dividing MAX_INT or something. > > See for example kmalloc_array(), which does > > if (size != 0 && n > SIZE_MAX / size) > return NULL; > > exactly to avoid the overflow when it does the "n*size" allocation. > > So for multiplication, we really *could* use overflow logic. It's not > horribly common, but it definitely happens. > Based in part on an old patch by Sasha, what if we relied on CSE: if (mul_would_overflow(size, n)) return NULL; do_something_with(size * n); I haven't checked, but it would be sad if gcc couldn't optimize this correctly if we use the builtins. The downside is that I don't see off the top of my head how this could be implemented using inline asm if we want a fast fallback when the builtins aren't available. --Andy