From patchwork Tue Nov 22 22:54:06 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 101465 Delivered-To: patch@linaro.org Received: by 10.140.97.165 with SMTP id m34csp2355384qge; Tue, 22 Nov 2016 14:55:11 -0800 (PST) X-Received: by 10.98.8.84 with SMTP id c81mr43563pfd.114.1479855311532; Tue, 22 Nov 2016 14:55:11 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 98si1857355plb.215.2016.11.22.14.55.11; Tue, 22 Nov 2016 14:55:11 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of stable-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 stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934541AbcKVWzK (ORCPT + 3 others); Tue, 22 Nov 2016 17:55:10 -0500 Received: from mout.kundenserver.de ([212.227.17.13]:65259 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933931AbcKVWzJ (ORCPT ); Tue, 22 Nov 2016 17:55:09 -0500 Received: from wuerfel.lan ([78.43.21.235]) by mrelayeu.kundenserver.de (mreue104 [212.227.15.145]) with ESMTPA (Nemesis) id 0LyDKf-1clw2k0RQz-015cxM; Tue, 22 Nov 2016 23:54:39 +0100 From: Arnd Bergmann To: Andrey Ryabinin Cc: Arnd Bergmann , =?utf-8?q?Martin_Li=C5=A1ka?= , Andrey Ryabinin , stable@vger.kernel.org, Michal Marek , Alexander Potapenko , Dmitry Vyukov , linux-kbuild@vger.kernel.org, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org Subject: [PATCH] kasan: turn off -fsanitize-address-use-after-scope for now Date: Tue, 22 Nov 2016 23:54:06 +0100 Message-Id: <20161122225424.3739294-1-arnd@arndb.de> X-Mailer: git-send-email 2.9.0 MIME-Version: 1.0 X-Provags-ID: V03:K0:wP8kWKPxQVPS9w8C2YPPzBQ8W6Yn0cUK8qE9MfO7Ffvx1jUBc6D xpgrMEFxkBsCfiFJXqj0H2iyXA+ZGllx3rHL+IRoH661ml2LNQScAosKg2VsMZChSSZBqSu lVnp7w8dBR3uEWpOHDYdGwnnTG3u/fy1Hb9YPYerpp9JfjZa2vJ3uuQdvE4LWw5+L3ME1iW qo5Ws+s9pf5GWo4Q5XBGw== X-UI-Out-Filterresults: notjunk:1; V01:K0:P5T9AL4maDo=:D3bev7d8jxDbs7eGmdF5p5 ixUian/f59Tx+BeaqgnYs+k90AB3buTVIARfh38AXzWvx8OQdkxkoDXIX7yzIUxG7DsTG3gLT sOWFfIwEVdjiN/zGeqR/B1JNwvd+j9joGN8jmf7gqBCDoM7Qa/2bgYDJI0bh0r07PMLOVQXNk sQyXFJYnhID1hHB2auXiPVm41PCsi0pQX0zlQpDGEORk/BnSKjrSyyiHi1UVTi8W2JKbiSQz5 JFLWrgOR1z02KGht21DMj87iZHF1Vd/mnp8GSoreWxNVhXewBgK8QpErPKOUVa07qRjcNGEY8 CNAVxUi1uGCVBzPJSBra48oXpckwnPBLi2QMuHjYd7Z4DKVjFgnctC6/Tf4neQ3jR0NHByDOg i5vNbD1LruiZuYp0wQPOP7IxJSPQZSPPywgP3H1oW5SUNDo1dzdQ9xG9Ls3hPunUEC+X1r0rY q2pUIvY/OpoA/1kpKm/DZk6zgZOXFp6dlX/KaHTArKyhxqg6WXswYj1RKUA6h/Dv3pSNDKqfZ tUHgEATvFF/dL+Yy7OIzgM3XNKutkoQqy2nCtoAzPjwNnREckhH3P50wm4zNmc4H49Yr6Uz1v sybeBJuRvnqfe+Sk1NOMTOOfmfM+b/J4Zaidnb+mgQBv7oUxhAjgvfJBCAMDMUChxZiC57STr CGEbqWEZeN8EhRmep283TeuF4gZijQLSpZpRyo82fZczQSJPL14RRXA6D8HR+bUqvVTM6vzwg H7QJBGTB1rnUGXyM Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org In the upcoming gcc-7 release, the -fsanitize=kernel-address option implies -fsanitize-address-use-after-scope, which relies on the definition of two global functions, causing many link errors if they are not defined, e.g: arch/x86/built-in.o: In function `x86_pmu_handle_irq': (.text+0x88e6): undefined reference to `__asan_unpoison_stack_memory' arch/x86/built-in.o: In function `x86_pmu_handle_irq': (.text+0x8ad7): undefined reference to `__asan_poison_stack_memory' kernel/built-in.o: In function `perf_tp_event': (.text+0x225472): undefined reference to `__asan_unpoison_stack_memory' kernel/built-in.o: In function `perf_tp_event': (.text+0x22583a): undefined reference to `__asan_unpoison_stack_memory' kernel/built-in.o: In function `perf_tp_event': (.text+0x2258ae): undefined reference to `__asan_poison_stack_memory' kernel/built-in.o: In function `perf_event_aux_event': I think we really want to define those two functions so we can make use of a helpful feature, but as I have no idea what they are supposed to do, I'd suggest to turn the option off on existing kernels to allow building with gcc-7 and kasan. For some reason, the problem showed up in only a few randconfig builds, but it is easy to reproduce using an x86-64 tinyconfig build with CONFIG_KASAN=y. If we decide to take this approach, we probably want to do the same change on all stable kernels that support KASAN, i.e. v4.0 or higher. Link: https://gcc.gnu.org/viewcvs/gcc?limit_changes=0&view=revision&revision=241896 Cc: Martin Liška Cc: Andrey Ryabinin Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann --- scripts/Makefile.kasan | 2 ++ 1 file changed, 2 insertions(+) -- 2.9.0 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan index 37323b0df374..0e68fef09f76 100644 --- a/scripts/Makefile.kasan +++ b/scripts/Makefile.kasan @@ -29,3 +29,5 @@ else endif endif endif + +CFLAGS_KASAN += $(call cc-option, -fno-sanitize-address-use-after-scope)