Received: by 2002:ac0:a679:0:0:0:0:0 with SMTP id p54csp788456imp; Wed, 20 Feb 2019 09:02:44 -0800 (PST) X-Google-Smtp-Source: AHgI3IYvtG1Qw7L1H/czc8FQjziNPsEZNVDMyDcIpnSzurojwwjO3vEvPq53FHazWpoVO2SM07KU X-Received: by 2002:a62:b242:: with SMTP id x63mr23963512pfe.4.1550682164646; Wed, 20 Feb 2019 09:02:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550682164; cv=none; d=google.com; s=arc-20160816; b=EoSfm9qpnqxCW6tHU5DGibUprcNtsc+nANgLCPSdcBEGzob7jorlpxpIo88j3CV6M+ GERb7KwRDOkl5OjkysbFgJ5u6VPs4Ebkc7iMk9U6XIOys9Ah9vyTOY0+I4H1fvyBTZit VNNbgGvVawPI9WStyVF8NRVeAfKAyxv2o9obC8uBBJdyffk3HPdLubQZqvQL65fUKuyR M0wPGDNN0G6VX7oZryqod0p6VDeGIwq1S26aimdT1/xaJm1GE5QayaIZImvL7xRBe0+3 1BunLEwK8sfJDV6iICQhiQV7kcIs9he+Nk3x1gsuljVBXBwrBrIPLJXzCAZW393mWOJk bcew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=jQ+f2lVQvTIvLkhAg9F3pLaIJ001Slwq94ewNL82igM=; b=Ezf7H/mS4xDZGfPkuWNRfMMRXeNQOXn29xtDwRa8tNsIFiuDGQFe/n0tlxJSmNC8pr 6rXZG+rcV0lRQBEj/H1+rPX9xoBKJ8N8dzSPYwzL9Xclpu+60a5DC2HfzPgn8s+41mmw WYv6f5SqPqYHpO6w9UTMoE3pBoAXcW6jo0m93SyBeX5sqyTVTofltGMV3Y0k/qrPC30A Lq/+94zvNBvRln7SyvIt5FJCBNMw4Ozk5VB9qUuPRcNU7okkwo9tUh/cdvEK+shI637m /VUEDVW0wAoReav6GU3ScXY0KFsBOaWpluPJow0pjK5soTeeohL99eFNEJVgBtAplnyx vb3g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ay3si19244439plb.58.2019.02.20.09.02.26; Wed, 20 Feb 2019 09:02:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726648AbfBTRAZ (ORCPT + 99 others); Wed, 20 Feb 2019 12:00:25 -0500 Received: from relay.sw.ru ([185.231.240.75]:46554 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725801AbfBTRAZ (ORCPT ); Wed, 20 Feb 2019 12:00:25 -0500 Received: from [172.16.25.12] by relay.sw.ru with esmtp (Exim 4.91) (envelope-from ) id 1gwVEH-0003Zn-Uj; Wed, 20 Feb 2019 20:00:18 +0300 Subject: Re: [PATCH] kasan: turn off asan-stack for clang-8 and earlier To: Arnd Bergmann , Andrey Konovalov Cc: Masahiro Yamada , Michal Marek , Andrew Morton , Dmitry Vyukov , Nick Desaulniers , Mark Brown , Qian Cai , Alexander Potapenko , Martin Schwidefsky , Christoph Lameter , LKML , Linux Kbuild mailing list , kasan-dev References: <20190219214940.391081-1-arnd@arndb.de> From: Andrey Ryabinin Message-ID: Date: Wed, 20 Feb 2019 20:00:37 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/20/19 5:51 PM, Arnd Bergmann wrote: > On Wed, Feb 20, 2019 at 3:45 PM Andrey Konovalov wrote: >> >> On Tue, Feb 19, 2019 at 10:49 PM Arnd Bergmann wrote: >>> >>> Building an arm64 allmodconfig kernel with clang results in over 140 warnings >>> about overly large stack frames, the worst ones being: >>> >>> drivers/gpu/drm/panel/panel-sitronix-st7789v.c:196:12: error: stack frame size of 20224 bytes in function 'st7789v_prepare' >>> drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c:196:12: error: stack frame size of 13120 bytes in function 'td028ttec1_panel_enable' >>> drivers/usb/host/max3421-hcd.c:1395:1: error: stack frame size of 10048 bytes in function 'max3421_spi_thread' >>> drivers/net/wan/slic_ds26522.c:209:12: error: stack frame size of 9664 bytes in function 'slic_ds26522_probe' >>> drivers/crypto/ccp/ccp-ops.c:2434:5: error: stack frame size of 8832 bytes in function 'ccp_run_cmd' >>> drivers/media/dvb-frontends/stv0367.c:1005:12: error: stack frame size of 7840 bytes in function 'stv0367ter_algo' >>> >>> None of these happen with gcc today, and almost all of these are the result >>> of a single known bug in llvm. Hopefully it will eventually get fixed with the >>> clang-9 release. >>> >>> In the meantime, the best idea I have is to turn off asan-stack for clang-8 >>> and earlier, so we can produce a kernel that is safe to run. >> >> Hi Arnd, >> >> I don't think it's good to disable KASAN stack instrumentation for the >> whole kernel by default with clang. It makes more sense to disable >> stack instrumentation only for these few drivers. > > Do you mean just the 114 files that we get warnings for in allmodconfig, > or also those that run into the same bug but stay below the warning limit, > and the ones that don't warn in allmodconfig but do warn in other > configurations? > > I would have to some more research, but I expect several hundred > patches before we get to a clean randconfig build with a broken > compiler. Manually maintaining asan-stack parameter for the sake of one broken compiler isn't a great idea either. Couple alternative suggestions: 1) If we can't fix the problem or the cost of fixing is too high, maybe just hide it? Disable -Wframe-larger-then on pre clang-9 compilers. 2) Fallback cflags. The idea is to try to compile every the file with "-mllvm -asan-stack=1 -Wframe-larger-than=2048 -Werror" at first, and fallback to "-mllvm -asan-stack=0" if failed. So it would be something similar to $(call cc-option, -mllvm -asan-stack=1 -Wframe-larger-than=2048 -Werror, -mllvm -asan-stack=0) except that "cc-option" tries options only once on some code example while we need to try options on every file that we actually compile. Honestly, I'm not sure that it's worthy to hack Kbuild engine for that particular use-case.