Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1185-g841157300a-fm-20221208.002-g84115730
Mime-Version: 1.0
Message-Id: <aa26bed0-dd8e-4fac-9606-91769eee96b8@app.fastmail.com>
In-Reply-To: <20221216160841.2061759-1-glider@google.com>
References: <20221215162956.4037570-1-arnd@kernel.org>
 <20221216160841.2061759-1-glider@google.com>
Date:   Fri, 16 Dec 2022 19:29:53 +0100
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Alexander Potapenko" <glider@google.com>,
        "Arnd Bergmann" <arnd@kernel.org>
Cc:     "David S . Miller" <davem@davemloft.net>,
        "Herbert Xu" <herbert@gondor.apana.org.au>,
        linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] crypto: wp512: disable kmsan checks in wp512_process_buffer()
Content-Type: text/plain
Precedence: bulk

On Fri, Dec 16, 2022, at 17:08, Alexander Potapenko wrote:
>> The memory sanitizer causes excessive register spills in this function:
>
>> crypto/wp512.c:782:13: error: stack frame size (2104) exceeds limit (2048) in 'wp512_process_buffer' [-Werror,-Wframe-larger-than]
>
>> Assume that this one is safe, and mark it as needing no checks to
>> get the stack usage back down to the normal level.
>
> KMSAN indeed bloats the stack frames heavily.
> Wouldn't it be more preferable to further increase KMSAN's 
> -Wframe-larger-than limit instead?
> It is not intended for production anyway, and detecting a runtime stack 
> overflow in the debug mode should not be a problem.

I don't actually see a lot of compiler warnings with KMSAN
hitting the limit, I think we can deal with them individually.

I'd rather not raise the limit more, as that makes it harder
to identify functions that use more stack than they should.

    Arnd