From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C600C43381 for ; Wed, 20 Feb 2019 21:40:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3E64F2086C for ; Wed, 20 Feb 2019 21:40:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727107AbfBTVkt (ORCPT ); Wed, 20 Feb 2019 16:40:49 -0500 Received: from mail-qk1-f195.google.com ([209.85.222.195]:34497 "EHLO mail-qk1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726137AbfBTVks (ORCPT ); Wed, 20 Feb 2019 16:40:48 -0500 Received: by mail-qk1-f195.google.com with SMTP id a15so3044930qkc.1; Wed, 20 Feb 2019 13:40:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=czh+n0Hqrebi2h82qZBwQ4Zi9TeI84X+itSN75yXDUo=; b=GVJhqg5fnmpC5BYSy4viIFKFs8YgV91qWg2um119zvqNoFMGMdVq1l0VslbpDpiDZJ hpVvWvrAgj5GrneddW2+Hg38+a9ZIbS6TgQJ7EV/eKCEewqj2Fy7xZ5TICSBdFFuoR5J yO0J1or90UvUKjkIf4Ky0wbY+FNtJETlHJ5JzXa5/AHEahRWLt5CZ6ZXN9TW51SFOyUI TIu41gIrNzmyoJRLSZ3uBhmlP/zoqMCwkDi387NY6hYyOzzzsWrPwIlMiqjM76nnRTqJ OtXNHGj7j3RjVL7e0rzZnAVBm46OlBh4aUiFwoQDMqraITEmwBtuBvqumXFinpJhsTcC wclw== X-Gm-Message-State: AHQUAub/9K/0XK5P5Oo6yk+HU+AQKKHspSbhFmU7U7ZjBjFmHsmf0c+9 rxEa2en5zuOUX/raCaT2TF7m3km5uqmxhxfu7H8= X-Google-Smtp-Source: AHgI3IZLue5+DXekspfQoDlSfnEgiMu9Tuv/OESHntUBeCCJmGmDF6xbTkYtryrqTtVKMQ59SbCJx3o6FprqdZGc0hY= X-Received: by 2002:a37:7cf:: with SMTP id 198mr26611663qkh.173.1550698847364; Wed, 20 Feb 2019 13:40:47 -0800 (PST) MIME-Version: 1.0 References: <20190219214940.391081-1-arnd@arndb.de> <20190220184408.GG9878@sirena.org.uk> In-Reply-To: From: Arnd Bergmann Date: Wed, 20 Feb 2019 22:40:29 +0100 Message-ID: Subject: Re: [PATCH] kasan: turn off asan-stack for clang-8 and earlier To: Nick Desaulniers Cc: Mark Brown , Kostya Serebryany , Evgenii Stepanov , Andrey Ryabinin , Andrey Konovalov , Masahiro Yamada , Michal Marek , Andrew Morton , Dmitry Vyukov , Qian Cai , Alexander Potapenko , Martin Schwidefsky , Christoph Lameter , LKML , Linux Kbuild mailing list , kasan-dev Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 20, 2019 at 10:13 PM Arnd Bergmann wrote: > > In the example in https://bugs.llvm.org/show_bug.cgi?id=38809#c12 > (https://godbolt.org/z/ylsGSQ) there is no inlining, yet clang uses > over ten times as much stack space as gcc, for reasons I still > can't explain. My assumption right now is that the underlying bug > causes most of the problems with excessive stack usage in > allmodconfig kernels. Here is an even more minimal example: struct s { int i[5]; } f(void); void g(void) { f(); f();} https://godbolt.org/z/d_KWkh It's clear that clang does /something/ here when asan-stack=1 is set, but I fail to see what it is, or why that is necessary. The output of clang with asan-stack=0 is the expected code, and basically identical to what gcc produces with or without asan-stack. Arnd