Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp705935pxb; Thu, 9 Sep 2021 10:06:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxHwRXSWiXo5YP0Fn/9LIWP3s5vB+K4upxrrhLjZeR4jk6egk8ovXR2QHH1O5vgQRY/69QU X-Received: by 2002:a05:651c:902:: with SMTP id e2mr757949ljq.304.1631207219140; Thu, 09 Sep 2021 10:06:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631207219; cv=none; d=google.com; s=arc-20160816; b=emdUiXh8MEo7UJoKOMI0G/xYIc9M79iwX3ctkv5uZNvCyxp8mvcaWsyaRyouDiq7J6 3MnpQp0iRGXlYqcMoE3QVdUK3V1C8CRI+LRxcJR2M8eIHPZ4GA03j5rWQYulwpYYgGP9 fBqActE7vopiFFBXwcFvHafd3gWI35ht15+l59ucKbII+7aLskl2OT0lEc4GlkaHbTbI 4j3o9vOGtysHagSYrz7YL5EsahfUhwcwUzTqkgxE8wJ5dOwrC/xlt0C+XJb2L9QMhNvE 7o03w+UckGFFaV4AWShtcxwo2jIzxU8hvh0WSdmnwFo/Y5zS7Dh5J8XrHWfiORWkDUxT 28Gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=dZAGO3iBrhQAq7cxABN7v0YxXWtGf0YiblsBwMfWyrc=; b=L8RS/ctPxLghs5J5TwHe9x38+P3v/JYNNYtMZEB07+MrGIZvu7n96W1mDGOGwVFM+N xGDq6/nBf2ESsCBW2s6z0ui7bnInq43yIS9uMeyTBSSGfqIE9vbIuywn05O41c3FjtC5 hNe1VS3vzuNLiOYZKuemuIIzq4zKy72D77YwnYtKFX025cxht1t1ih5E7+didLdSJq6c SxxqmNGwPBGsm3BKJHdqbIktSnT/iBuUQTyb0yTOfcbFyYC/IfQsCSHmrrNEom7fByRj 903iRmilczQAdIs5U24IRhg7HHv94QUNo722al5fcWvDHc8pyk2NISRsdA+uUKpQtUtD KwUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=OWJMz8LL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r25si2194382ejc.100.2021.09.09.10.06.29; Thu, 09 Sep 2021 10:06:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=OWJMz8LL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240681AbhIIRDA (ORCPT + 99 others); Thu, 9 Sep 2021 13:03:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51640 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240716AbhIIRC5 (ORCPT ); Thu, 9 Sep 2021 13:02:57 -0400 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DAD33C061574 for ; Thu, 9 Sep 2021 10:01:47 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id g22so3557784edy.12 for ; Thu, 09 Sep 2021 10:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dZAGO3iBrhQAq7cxABN7v0YxXWtGf0YiblsBwMfWyrc=; b=OWJMz8LLr85sFM8RFy9k59A+OTyiaRWf0ZZ0n6Rcq7tOz8KHuQoirSrp+zkJs09eDI qXHOeRQalPKLdGml0NfQEcoEgcJ4RTyh7hAsLCSL/ndaFI7PDIP4NyPdrC6LqlqN47u+ Tal0cn+jttYnbxNfFIYPgA5YVSh9fCfn1aRs4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dZAGO3iBrhQAq7cxABN7v0YxXWtGf0YiblsBwMfWyrc=; b=xSV6eYL8vD7lumN5ISeOVHpfalV8Zq7RjZWr4zN4Z5wiT6SUfcuCxSc1RcgcHum+sC M0+PzyrDsZFmGgqDIJkbV3VMrU2neUYibncbFm991JJy7JMR6aCg1vmof74O8mnsBdwF RuB8cXkHTjABauH3KLBm0QZI166GyyVbZYjBSOCpw1xIu3o1rsCG4v60kMc4Q3h+H44v meV6B+wjsEKiDolCfQSN6bl92rmvzG/UYms6jYP1u95VcWy4Hke+VtUB7T1hrBtUf16b bj3mkJW36QqiOsOis6kLvXkID9b/9jwHJWKg6YaOfZ7dNdEUDRvkpG4XQSd4X8K6PR0w 4Sig== X-Gm-Message-State: AOAM530PT6vnUW2YDOXSpWuBxbnUx6iti/Lmln5FtB3DnoKiob6UYdQZ tmGYeioEY1bepbIS1yJQXuGco+93qMYWXXEQqE4= X-Received: by 2002:aa7:c649:: with SMTP id z9mr4210636edr.304.1631206906192; Thu, 09 Sep 2021 10:01:46 -0700 (PDT) Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com. [209.85.221.44]) by smtp.gmail.com with ESMTPSA id i26sm895562edj.88.2021.09.09.10.01.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Sep 2021 10:01:46 -0700 (PDT) Received: by mail-wr1-f44.google.com with SMTP id q26so3537856wrc.7 for ; Thu, 09 Sep 2021 10:01:46 -0700 (PDT) X-Received: by 2002:a05:6512:3da5:: with SMTP id k37mr583246lfv.655.1631206431030; Thu, 09 Sep 2021 09:53:51 -0700 (PDT) MIME-Version: 1.0 References: <20210906142615.GA1917503@roeck-us.net> <75a10e8b-9f11-64c4-460b-9f3ac09965e2@roeck-us.net> In-Reply-To: From: Linus Torvalds Date: Thu, 9 Sep 2021 09:53:35 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] Enable '-Werror' by default for all kernel builds To: Marco Elver Cc: Arnd Bergmann , Christoph Hellwig , Guenter Roeck , Nathan Chancellor , Linux Kernel Mailing List , llvm@lists.linux.dev, Nick Desaulniers , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Andrey Konovalov , kasan-dev , =?UTF-8?Q?Christian_K=C3=B6nig?= , "Pan, Xinhui" , amd-gfx list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 9, 2021 at 4:43 AM Marco Elver wrote: > > Sure, but the reality is that the real stack size is already doubled > for KASAN. And that should be reflected in Wframe-larger-than. I don't think that's true. Quite the reverse, in fact. Yes, the *dynamic* stack size is doubled due to KASAN, because it will cause much deeper callchains. But the individual frames don't grow that much apart from compilers doing stupid things (ie apparently clang and KASAN_STACK), and if anything, the deeper dynamic call chains means that the individual frame size being small is even *more* important, but we do compensate for the deeper stacks by making THREAD_SIZE_ORDER bigger at least on x86. Honestly, I am not even happy with the current "2048 bytes for 64-bit". The excuse has been that 64-bit needs more stack, but all it ever did was clearly to just allow people to just do bad things. Because a 1kB stack frame is horrendous even in 64-bit. That's not "spill some registers" kind of stack frame. That's "put a big structure on the stack" kind of stack frame regardless of any other issues. And no, "but we have 16kB of stack and we'll switch stacks on interrupts" is not an excuse for one single level to use up 1kB, much less 2kB. Does anybody seriously believe that we don't quite normally have stacks that are easily tens of frames deep? Without having some true "this is the full callchain" information, the best we can do is just limit individual stack frames. And 2kB is *excessive*. Linus