Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933178AbdLRJQr (ORCPT ); Mon, 18 Dec 2017 04:16:47 -0500 Received: from mail-oi0-f66.google.com ([209.85.218.66]:35674 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758178AbdLRJQm (ORCPT ); Mon, 18 Dec 2017 04:16:42 -0500 X-Google-Smtp-Source: ACJfBouGH88KkMOw8DSMZ5Cbk5BwgpYwZgfe1h3FLwAmlVzCC7wm+nw/n4YAch46tGJ6ZS5N/az+0yGrIl9Mb18DOqM= MIME-Version: 1.0 In-Reply-To: <2276602.9klaxVRupl@blindfold> References: <20171011135419.3492681-1-arnd@arndb.de> <2276602.9klaxVRupl@blindfold> From: Arnd Bergmann Date: Mon, 18 Dec 2017 10:16:41 +0100 X-Google-Sender-Auth: com9X3sE6nI70Do5l_j9XDcGVAM Message-ID: Subject: Re: [PATCH] mtd: cfi: convert inline functions to macros To: Richard Weinberger Cc: David Woodhouse , Brian Norris , Boris Brezillon , Marek Vasut , Cyrille Pitchen , "# 3.4.x" , linux-mtd , Linux Kernel Mailing List 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: 2692 Lines: 52 On Sun, Dec 17, 2017 at 9:34 PM, Richard Weinberger wrote: > Am Mittwoch, 11. Oktober 2017, 15:54:10 CET schrieb Arnd Bergmann: >> The map_word_() functions, dating back to linux-2.6.8, try to perform >> bitwise operations on a 'map_word' structure. This may have worked >> with compilers that were current then (gcc-3.4 or earlier), but end >> up being rather inefficient on any version I could try now (gcc-4.4 or >> higher). Specifically we hit a problem analyzed in gcc PR81715 where we >> fail to reuse the stack space for local variables. >> >> This can be seen immediately in the stack consumption for >> cfi_staa_erase_varsize() and other functions that (with CONFIG_KASAN) >> can be up to 2200 bytes. Changing the inline functions into macros brings >> this down to 1280 bytes. Without KASAN, the same problem exists, but >> the stack consumption is lower to start with, my patch shrinks it from >> 920 to 496 bytes on with arm-linux-gnueabi-gcc-5.4, and saves around >> 1KB in .text size for cfi_cmdset_0020.c, as it avoids copying map_word >> structures for each call to one of these helpers. >> >> With the latest gcc-8 snapshot, the problem is fixed in upstream gcc, >> but nobody uses that yet, so we should still work around it in mainline >> kernels and probably backport the workaround to stable kernels as well. >> We had a couple of other functions that suffered from the same gcc bug, >> and all of those had a simpler workaround involving dummy variables >> in the inline function. Unfortunately that did not work here, the >> macro hack was the best I could come up with. >> >> It would also be helpful to have someone to a little performance testing >> on the patch, to see how much it helps in terms of CPU utilitzation. >> >> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 >> Cc: stable@vger.kernel.org >> Signed-off-by: Arnd Bergmann > > Acked-by: Richard Weinberger Thanks! > Marek, I know you are not super happy with this patch but IMHO this is the > solution with the least hassle. > While functions offer better type checking I think this functions are trivial > enough to exist as macros too. > Also forcing users to upgrade/fix their compilers is only possible in a > perfect world. Right. To clarify, this is a potential security issue, as it might be used to construct a stack overflow to cause privilege escalation when combined with some other vulnerabilities. I'd definitely want this backported to stable kernels as a precaution, and I'm preparing a patch to warn about this kind of problem again in 'allmodconfig' kernels that currently disable the warning on arm64 and x86. Arnd