From: Arnd Bergmann Subject: Re: [PATCH] [RFT] crypto: aes-generic - turn off -ftree-pre and -ftree-sra Date: Wed, 3 Jan 2018 21:38:30 +0100 Message-ID: References: <20171220205213.1025257-1-arnd@arndb.de> <20171220214648.GO2353@tucnak> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: PrasannaKumar Muralidharan , Jakub Jelinek , Herbert Xu , James Morris , Richard Biener , Jakub Jelinek , "David S. Miller" , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , Linux Kernel Mailing List To: Ard Biesheuvel Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org On Wed, Jan 3, 2018 at 6:36 PM, Ard Biesheuvel wrote: > On 3 January 2018 at 16:37, Arnd Bergmann wrote: >> On Fri, Dec 22, 2017 at 4:47 PM, Ard Biesheuvel wrote: >> >> A minimal patch would be to disable UBSAN specifically for aes-generic.c >> for gcc-7.2+ but not gcc-8 to avoid the potential stack overflow. We could >> also force building with -Os on gcc-7, and leave UBSAN enabled, >> this would improve performance some 3-5% on x86 with gcc-7 (both >> 7.1 and 7.2.1) and avoid the stack overflow. >> > > Can't we just disable UBSAN for that file for all GCC versions and be > done with it? It is not a production feature, and that code is > unlikely to change in ways where UBSAN would make a difference anyway, > nor is it ever executed on 99.9% of systems running Linux. It's up to Herbert in the end. I'm leaning to the -Os change in the Makefile, since it improves the performance for the common case as well, and once we start disabling UBSAN for performance-critical files, it becomes a slippery slope. I'll send the patch with the -Os change as v2, and note the ubsan-disabling alternative in the changelog. Arnd